Re: Forth Frustrations

On Apr 8, 10:06 pm, Elizabeth D Rather <erather...@xxxxxxxxx> wrote:
J Thomas wrote:

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.

Why not? Above, you have two definitions instead of one. What does
this achieve? And using ACTION: to define the name (and not the action)
is pretty counter-intuitive.

Not two definitions. One nameless definition. Then if you like add it
to the dictionary. Defining what action to give to a name may seem
counterintuitive until you notice the other choices are VALUE: and
DOES: . I currently have three kinds of names. I could reduce that to
two, but I'm not sure yet that two are better.

Similarly, do all the dictionary stuff once, when it's ready.

As opposed to ... ? Who does it more than once?

Traditional Forth compiles the header at the beginning and unsmudges
it at the end. You have to continue to track it, and if you put that
data on the control-flow stack you have a colon-sys. What do you gain
by doing it at the beginning instead of the end? It might seem
familiar to have the name at the beginning. (But I remember when I
first started learning Forth it was not intuitive that the first name
had a completely different meaning from the rest.) If your headers are
scattered among the code then you get the advantage of knowing just
where the code starts relative to the header. Perhaps you must do a
little arithmetic to get past the name, but even that goes away if the
name is stored as a count and the first three characters, or a
consistent-size hash. But if the header space is separate from code
space then the minor advantage from defining the header before the
code disappears.

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.

What's the problem with this?

It isn't a big problem. It's a little clumsy. :NONAME definitions are
something special instead of just the default that you can change when
you want to.

When I looked at it from the beginning, I wanted a simple interface to
the dictionary. Give an xt and a name to the command that adds to the
dictionary, and it adds the new name to the dictionary. It doesn't get
simpler than that. The obvious time to provide an xt is after the code
is complete, and the obvious time to provide a name is when you use
it.

And of course the replacement for DOES> should go at the end. If
you're going to associate nameless code with an address, it makes
sense to have the nameless code ready before you start. And it makes
sense to make a new definition instead of changing an existing one.
There's no need to restrict DOES> to the last CREATEd definition,
there's no need to restrict it at all -- except that you don't want to
have to choose what to use when you always use the same thing.

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.

Well, holding it on the stack seems unnecessarily complicated, but I
don't know anyone who does this. We normally compile to the place where
the definition will go. There's no waste motion.

What is colon-sys but dictionary information? (plus maybe an xt.) You
don't put *all* the dictionary information on the stack (or in
variables) but you need some because you have to go back and change
things later.

I just don't see what problem you're solving. This looks more
complicated, not less.

That's only natural because you're used to the old way. And what you
do works perfectly well even though it's unnecessarily complex in
minor ways. It evolved incrementally, and various of the choices were
natural and seemed ideal when headers and code and data were all
mixed. And even if some things that involve the dictionary have
unneeded complexity, you never spend a lot of time adding things to
the dictionary so it doesn't cause an important speed penalty.

If you were to streamline your Forths you'd have a massive problem
with your customer base who know how to do things the old way, and the
gains couldn't be worth it. I wouldn't want something like a Forth-83
change where the people who like the new way all switch and the people
who like the old way dwindle away and over some years quit using
Forth. That's no good.

So I want to be able to put a compatibility layer on compilers that
run my way so they can run your way, and a compatibility layer on
compilers that run your way so they can run my way. Ideally be able to
switch a compiler back and forth, probably by changing search order.
Then I believe my approach leads to a simpler kernel and to more
powerful application code. Individual system developers and individual
programmers might switch at their own pace without a lot of uproar.
And if nobody but me switches then the only problem is that my code
gets harder to read.

I think this approach can widen the scope for innovation. Anybody can
do what they want with their own Forth, and the only result is they
have a Forth that runs nonstandard code and they have code that runs
only on their Forth, and mostly everybody else ignores them. But if
you can do something interesting that will run on standard Forths, and
you can implement a standard Forth on systems that have the new
feature integrated, then your innovation is for all practical purposes
standard and it has a much better chance to become common practice.


.

Relevant Pages

  • Re: C++0x: Scaling up on weak foundations?
    ... I think backward compatibility is a weak foundation to build upon and the ... Well I'm designing my own language. ... You should prefer to make it not compile instead of fail ... For this purpose there are standard header ...
    (comp.lang.misc)
  • Re: Check for uncompiled code
    ... The compile date, time, flash-compile [ ... internal item header from all processors. ... date, time user, and number of flash frames used (zero if not flash- ... 001 a update date for yupt hdr: ...
    (comp.databases.pick)
  • Re: Forcing compile-time error
    ... I am replacing calls to an outdated system function with a new wrapper ... and macro name. ... OldFunction is prototyped in the header files which ... compile error, but for every file that includes the ...
    (comp.lang.c)
  • Re: Forth Frustrations
    ... And when you heard the simple rule that all defining words are followed by the name of the thing being defined, ... where the code starts relative to the header. ... compile a previous word with the same name, ... sense to have the nameless code ready before you start. ...
    (comp.lang.forth)
  • Re: An Observation
    ... first character on the stack. ... parse a word and compile the value as a literal to use ... need to execute at compile-time for. ...
    (comp.lang.forth)