wmb@ENG.SUN.COM (02/09/90)
Paul Bartholdi describes some alternative syntax for Forth "look-ahead" words:
1. <name> : <some code> ;
Problem: If <name> is already defined, it will be executed instead
of "remembered for later". Ditto if it parses as a number
in the current base (e.g. feed faded dead beef face cafe, ace.
bed babe?)
2. {{ <some code> }} <end index> <first index> ITERATE
Advantage: With a scheme like this, it is possible to have one and
only one look-ahead word, instead of the jumble of them
that Forth has now.
3. ' <name> : <some code> ;
Pretty close in spirit to PostScript, but in reference to number 2
above,this would be better written as:
' <name> {{ <some code> }} :
or my preference:
{{ <some code> }} ' <name> :
That way, there remains one and only one way to create a "closure"
For reference, the actual PostScript syntax is:
/<name> { <some code> } def
I would have preferred if PostScript had instead used:
{ <some code> } /name def
because I find it advantageous to minimize the "lifetime" of
stack items. Fortunately, it is quite easy to implement this
change:
/newdef { exch def } def
> I don't see why a computer language should be pure in/pre/post fix.
Because every departure from "purity" places a roadblock in your path
at some point. For instance, Forth's prefix CREATE operator cannot
be used inside a colon definition to create a predefined word.
Many of the hotly-debated topics at ANSI Forth meetings arise from
places where Forth is not purely postfix. For example, "state-smartness"
and all its implications comes from non-postfix words.
Infix syntax in C-like languages creates a distinction between operators
that are "in the language" (and thus can have infix syntax) and operators
that the user can add (and thus must use procedure call syntax).
> If you find a 100% pure Postfix notation ...
PostScript comes pretty close. It has the following syntactic constructs,
and everything else is pure postfix:
Token Description (using Forth parlance)
{ Begin an unnamed colon definition, switching to
compile state if necessary.
} Terminate the colon definition started by the matching
{, switching out of compile state if at the highest nesting
level.
/name Reference or create a keyword "name" (this is sort of
like ' name in Forth, except that the new keyword will
be created if it doesn't already exist.
(string of text)
Enter a literal string.
One possible syntactic simplification would be to eliminate the "/" construct.
I believe that it would be possible to use (name) instead, and to automatically
coerce string types to keyword types when they are used. However, this would
be less convenient for the programmer, and possibly less efficient for the
interpreter.
It might also be possible to eliminate the { } construct, by adding a word
"compile" which operates on a string and converts it to something executable.
That would leave ( ) as the only syntactic entity.
In contrast, Forth has many more syntactic constructs; essentially every
immediate word has syntactic implications, plus every defining word and
every word which calls WORD .
Mitchdwp@willett.UUCP (Doug Philips) (02/12/90)
In article <9002082200.AA26319@jade.berkeley.edu> wmb@ENG.SUN.COM writes: > Paul Bartholdi describes some alternative syntax for Forth "look-ahead" words: > 2. {{ <some code> }} <end index> <first index> ITERATE > Advantage: With a scheme like this, it is possible to have one and > only one look-ahead word, instead of the jumble of them > that Forth has now. ... > That way, there remains one and only one way to create a "closure" Yes! Isn't this kind of simplicity in the 'spirit' of Forth? > Many of the hotly-debated topics at ANSI Forth meetings arise from > places where Forth is not purely postfix. For example, "state-smartness" > and all its implications comes from non-postfix words. ... > In contrast, Forth has many more syntactic constructs; essentially every > immediate word has syntactic implications, plus every defining word and > every word which calls WORD . I must disagree here. State-smartness and lookahead are separable issues. I don't want to say "One shouldn't be *able* to write things like WORD", but rather I want to ask "Wouldn't forth be cleaner if the core language was pure-postfix and didn't *do* anything like that?" -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]