Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!dsl.pitt.edu!pitt!willett!dwp From: dwp@willett.pgh.pa.us (Doug Philips) Newsgroups: comp.lang.forth Subject: Re: Postfixer FORTH Message-ID: <1534.UUL1.3#5129@willett.pgh.pa.us> Date: 16 Aug 90 05:21:36 GMT References: <9008152018.AA23733@ucbvax.Berkeley.EDU> Organization: String, Scotch tape, and Paperclips. (in Pgh, PA) Lines: 63 In <9008152018.AA23733@ucbvax.Berkeley.EDU>, DAVID@PENNDRLS.BITNET writes: > How about this for a more postfix FORTH syntax: > > " SomeWord" Is 20 Constant > " *2" Is : 2 * ; > > 'Is' factors out Create without changing the compiler significantly. > The Name field still gets laid down first. Defining words then > lay down a Code field at the current location, which is > conveniently right where it should go. I was going to reply that I thought your 'Is' was actually infix and not postfix. However, I think I'm too confused to say that with confidence. The point of postfix is that parameters are passed to functions and that the functions don't/shouldn't care how the parameters are created. I think your 'Is' example shows that the physically adjacency of the dictionary is not necessary are pure factoring. I agree with: 20 Constant ( and ) : 2 * ; being words that lay down code somewhere. I think that for 'Is' to be strictly postfix, the address of the code to be associated with the word should be on the stack along with the name for the word. What I think you have in your 'Is' is a form of deferred word that is immediately resolved. > Another idea I've been fooling with arose from a previous discussion > of Vocabularies as string recognizers. The argument was to enlarge > the scope of Number by implementing Vocabularies as generalized string > recognizers, with most of them doing it through table lookup in the > dictionary, but Number and similar routines doing it alogorithmically. > For instance, you could allow "x" to be recognized as a character > constant just as 5 is recognized as a numerical constant. In March 90, on comp.lang.misc Darren (Last name forgotten) "new@udel.edu" proposed a language he was working on called '2ol' which was just what you are talking about. The parser is a sequence of functions that each get a crack at the current token until one of them claims to have processed it. Of course, you could always pervert NUMBER to do something like that. The interpreter doesn't "know" that NUMBER only parses numbers, it just passes tokens to it. NUMBER could be a jump off point for what you are talking about (but then perhaps a better name would be less confusing.) > Once started down this path, though, you start to get into a lot of > delimited strings. For instance, "Something" could be Something as a > string constant, could be the Body address of Something, > and [Something] could Compile Something even if Something is Immediate. > I'm not sure I want to go that far, but . . . > > Now for the Big Question. Would this still be FORTH? I think it > would be. But it would *not* be Chuck Moore Forth, or ANS FORTH. I think it would be '2ol'. Whether or not that is Forth, I'm not sure. I think you could do something like that *in* Forth... -Doug --- Preferred: ( dwp@willett.pgh.pa.us OR ...!{sei,pitt}!willett!dwp ) Daily: ...!{uunet,nfsun}!willett!dwp [last resort: dwp@vega.fac.cs.cmu.edu]