Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!hellgate.utah.edu!cs.utexas.edu!uunet!willett!dwp
From: dwp@willett.UUCP (Doug Philips)
Newsgroups: comp.lang.forth
Subject: Re:  Why is Postscript not Forth?
Message-ID: <466.UUL1.3#5129@willett.UUCP>
Date: 14 Feb 90 01:58:18 GMT
References: <9002121713.AA24890@jade.berkeley.edu>
Organization: Latest link in the ForthNet chain.  (Pgh, PA)
Lines: 42

In article <9002121713.AA24890@jade.berkeley.edu>,
	wmb@ENG.SUN.COM (Mitch Bradley) writes:

> Which brings up the question:  What if we had a language with mostly
> PostScript syntax, but Forth "real machine, not overloaded" operators
> and "early binding" semantics?  That would be a nice language.  But
> does the world need yet another language that will not succeed for lack
> of a market?  Nope.
I've heard that CM himself is not worried about Forth's survivability.
How many PostScript engines are in place right now?  How does that
compare to Forth?  Which is the greater success?  Which would more
likely spawn a successful look-a-like?  (Not quite rhetorical questions,
because I only suspect the answers, I don't know for sure.)  Maybe
this would end up being a direction that Forth should go in?  But then
this gets back to the question of what the essence of Forth is and what
you can/can't change and still have Forth.

>  Aside: Forth: Virtual Machine or not?
> 
> There is a hot debate about whether Forth should be a "virtual machine"
> or a "high level assembler".  The essence of this debate is: "Should the
> bit-level details of how the dictionary is implemented be specified or
> not specified".  "virtual machine" advocates answer "yes", "high level
> assembler" (a poor name, by the way) advocates answer "no".
> 
> (I answer "no"; you may wish to take my further comments with a grain of
> salt based upon that admission).
I answer 'maybe'.  Perhaps what is needed is to avoid having to specify
'bit-level details of how the dictionary is implemented' and to start to
address the question of how to provide a set of words that will achieve
certain semantic-effect-manipulations of the dictionary.  The
definitions of those dictionary-smashing words will mostly likely be
non-portable, but code that uses them would be portable.  And depending on
how you define those words, they might even be immediate words that 'comma
in' to the word being defined fast code for direct manipulation, thus
avoiding one level of nesting and yet still not sacrifice portability.

		-Doug

---
Preferred: willett!dwp@gateway.sei.cmu.edu OR ...!sei!willett!dwp
Daily: ...!{uunet,nfsun}!willett!dwp   [in a pinch: dwp@vega.fac.cs.cmu.edu]