Re: I want to learn forth but...

rickman <gnuarm@xxxxxxxxx> wrote:
Jonah Thomas <jethom...@xxxxxxxxx> wrote:

And often the execution path would end up something like:

return return return return

A bunch of nested returns for no particular reason except that it
was too hard to avoid them. But I was just starting to learn Forth
and I figured that the smart guys had already tried the various
alternatives and this minor inefficiency was not worth improving.
Later I forgot about it.

Isn't tail recursion the typical optimization that avoids multiple,
cascaded returns? I think that is used in many Forths at this point.

Sure. Now here's my unimportant dilemma -- you can have the system do
that under-the-hood and keep it a secret from you, or you can have the
words to do it yourself. The first way looks obviously better in some
ways -- the system will be better at it than you are, the system will
never forget to do it, and it's one more thing that just works which you
don't need to think about.

On the other hand, it doesn't seem good to me for the system to do stuff
behind the Forth programmer's back. If you try to do things like R> DROP
to affect the nesting, it won't work right. That's OK in a way because
standard code isn't supposed to do that. You can write standard code and
treat the system as a black box that you know nothing about except the
inputs and the outputs, and your code will work with whatever
optimisations the systems programmer put in there for you. But in
another way it isn't as OK. If you did the tail-recursion yourself then
you'd know what was going on.

It looks to me like the same old problem, one where Forth traditionally
came down consistently on the side of letting the programmer know what
was going on, and this might be at the limit where that just isn't worth
doing. Or maybe it is still worth doing, despite the reasons against it.

Now Chuck has fixed a lot of those things, and I'd like to code his
way. But he wasn't interested in catering to an upgrade path from
existing Forth systems. It's a big jump to switch to a new Forth
that's very different.

Also keep in mind that many of Chuck's optimizations are for his
target. They either do not apply or are not as beneficial when used
on standard CPUs. For example, using a return instead of an ELSE
replaces a jump-return with a return. Yes, this is still an
improvement on a typical CPU, but not so much. Or maybe I'm wrong. A
pipelined machine requires stalls when the flow of control is not
linear. So I guess it would be two stalls vs. one.

It might not be as beneficial. But what does it cost? It looks to me
like the cost is entirely in the lack of standardization. It doesn't fit
with traditional code. But it could be made to fit. We don't have to use
Chuck's new syntax which is incompatible as hell with standard Forth.

But it ought to be possible to add the new ideas to old Forths. They
ought to be flexible enough to allow that.

I'm not so sure. The assumptions mentioned below include assumptions
that formed the current Forth body of work. When those assumptions
change (as Chuck has done) then the new ideas may not apply to the old
Forths.

If the old Forths can run the new code and the old code both, I don't
see that there's a problem. Your toolbox is bigger, and you choose the
tools you want.

Similarly I see no problem with having three different OO systems, or a
dozen different OO systems. I wouldn't even mind having three different
standard OO systems, if we knew that they were good for different
things.

Similarly there's no reason we can't have at least a couple of
different standard multitasking approaches. I like to think the reason
that didn't happen was that the standards people ran out of energy
before they got to it, and not that they couldn't agree on one single
best approach.

The same thing happens with learning. It's hard to accept that
everything you know is wrong.

If you know something that used to work, it's likely to keep working for
all the things you used to use it for. Wrong or not. If you have
something that works better then it makes sense to learn the better
approach because the old way is likely to stay competitive only inside a
shrinking niche. On the other hand, Forth appears to be competitive only
inside a shrinking niche, and yet it's so good for some things that it
makes sense not to forget about it.
.

Relevant Pages

  • Re: kids and their furniture?
    ... I would always honor and respect any house rules I was ... standards that differed significantly from the range of behaviors ... I think it's pretty close to the legal 'reasonable person' standard. ... too much work to reason one's way through every single ...
    (misc.kids)
  • Re: I dont get how the computer arrives at 2^31
    ... > Standard isn't always as careful with the language it uses. ... something that will make its functionality "equivalent" to fprintf(). ... function that created the va_list value passed to vfprintf(). ... The reason is that, unless ...
    (comp.std.c)
  • Re: How do you imagine future Common Lisp standard ?
    ... Scheme doesn't focus on good macro ... Goodness and Badness must be evaluated in a particular design-space ... It's fortunate that this can be done without change to the standard, ... There's no reason to define the old language away, ...
    (comp.lang.lisp)
  • Re: Understanding # and function variables
    ... That's the reason for my statement that I don't care whether a ... >>change is standard compliant or not. ... >>substantial revision of ANSI Common Lisp and would provide equally ... I will find out about an already existing language that is strictly ...
    (comp.lang.lisp)
  • Re: the media doesnt take christianity seriously
    ... >>the government imprison anyone or release anyone they wish for any reason ... >>Why do you believe no absolute standard of morality exists? ... > Our need to survive living with each other. ... That's just the opinion ...
    (rec.arts.tv)
Loading