Re: Forth Frustrations
- From: "J Thomas" <jethomas5@xxxxxxxxx>
- Date: 8 Apr 2007 17:58:18 -0700
On Apr 8, 5:07 am, Albert van der Horst <alb...@xxxxxxxxxxxxxxxxxx>
wrote:
J Thomas <jethom...@xxxxxxxxx> wrote:
-------
Summary: It is simpler to add words to the dictionary if the words are
defined first and then named. I propose three words that together
supply all the current defining words, and three words which expand on
VALUEs, DEFERed words, pointers, and DOES> constructions.
-------
IMO this is much like the PostScript approach. Certainly worth
a look at if you are interested in more systematic and sophisticated
if not more consequent handling of definitions.
Yes, I read something about PostScript being that way. And maybe
Stoic.
Your idea expressed PostScript-like:
\name equivalent to S" name" but it is put on the names stack.
{ is approximately :NONAME.} is approximately ;
DEFINE associates an xt with a name form the names stack.
\SQUARE { DUP * } DEFINE
Currently the way I'm doing it is
:: DUP * ;
ACTION: SQUARE
Why keep track of the name from the beginning? Bring it in when you
need it. Similarly, do all the dictionary stuff once, when it's ready.
Traditionally Forth started a definition, then you saw whether the
definition compiled. The definition was smudged in case you wanted to
compile a previous word with the same name, and when the compilation
ended correctly the name was unsmudged. Some systems hold dictionary
information on the data stack all the way through compilation, waiting
for it to be needed at the end! Do it once. Get the name and add it to
the dictionary once, when everything else is settled, and it's
simpler.
This would be interesting as an exercise to invent a neater
Forth-like language, not on top of ISO Forth.
I see no reason to write a new better Forth-like language to compete
with Forth in some of Forth's niches and fail. I prefer to write my
simpler Forth-like language on top of Forth-94, and also write
Forth-94 on top of my simpler language. Then my code is portable to
standard Forths, and if I or anybody else writes a clean simple
compiler that fits the new simpler "standard", it will be easy to add
a compatibility layer to provide the (I hope obsolescent) Forth-94
words. So my code is standard Forth and my compiler is standard Forth
and yet I get to have my improved system anyway.
I don't see any other halfway-adequate approach to innovation with
standard Forth. Forth 94 is in many ways adequate, and it tends to
discourage change. You can't make new things standard until they
become common practice, and it's hard to get common practice while
they're nonstandard.
My uncle once told me about a construction project he witnessed, where
it was impossible to replace the original building because a new
zoning requirement required an 80 foot setback front and back in a 220
foot lot. So they started making renovations, and he said that step by
step they carried the entire building out the front door, ending up
with a new building that officially was the old one. We don't need
anything that extreme because Forth 94 is mostly adequate. But the
general approach is worth attempting.
.
- Follow-Ups:
- Re: Forth Frustrations
- From: Bruce McFarling
- Re: Forth Frustrations
- From: Albert van der Horst
- Re: Forth Frustrations
- From: Elizabeth D Rather
- Re: Forth Frustrations
- References:
- Re: Forth Frustrations
- From: rickman
- Re: Forth Frustrations
- From: John Doty
- Re: Forth Frustrations
- From: J Thomas
- Re: Forth Frustrations
- From: Albert van der Horst
- Re: Forth Frustrations
- Prev by Date: Re: Structured Programming using Forth
- Next by Date: Re: Structured Programming using Forth
- Previous by thread: Re: Forth Frustrations
- Next by thread: Re: Forth Frustrations
- Index(es):
Relevant Pages
|
