Re: DISFAVORED Was: name for 3 PICK finally?

Andrew Haley <andrew29@[EMAIL PROTECTED]
> wrote:
> Jonah Thomas <jethomas5@[EMAIL PROTECTED]
> wrote:
> > Andrew Haley <andrew29@[EMAIL PROTECTED]
> wrote:
 
> >> We'd certainly spend a lot of time discussing what ahould be
> >> DISFAVOURED.  Top of my personal list would be STATE, then ROLL,
> >> then PICK...
> 
> > Since we've started that discussion, I'd nominate IMMEDIATE . It
> > isn't that often that you want the same word to do the same thing
> > whether compiling or interpreting.
> 
> That's fine, as long as you have _some_ way to make a word execute
> while compiling.  As long as you can do that, defining a word as
> COMPILER is fine.  I can't see the difference, really, as long as it
> works.

I haven't implemented this, it's just a morning idea. But -- we
currently have a lot of complication built around immediate words. They
execute while compiling, and the compiler has to know that. But then,
sometimes you do want to compile them so you have POSTPONE which has to
do the right thing with words that aren't immediate too. There were
enough problems with all tha, that Forth-94 declared most of the
standard special words to be particularly special -- you can POSTPONE
them but you can't use ' or ['] on them to get an xt. They're
compile-only meaning that a Forth system can make them do whatever it
wants in interpret-state. It's a big mess.

So, say we make the Forth-94 compile-only words be EXECUTE-ONLY. Get rid
of POSTPONE (meaning encourage people not to use it). Let users make
words be EXECUTE-ONLY too. An EXECUTE-ONLY word always executes and
never gets compiled -- just exactly like IMMEDIATE ! But not
state-smart. (Meaning encourage people not to use STATE as we've
encouraged them for 20+ years.) If you want to wait until later to
execute an execute-only word, then put it into a macro and execute the
macro whenever you want to.

If you want a little bit of safety, make some words COMPILE-ONLY . And
for a little bit more safety, a macro that includes a compile-only word
should become compile-only too.

That simplifies things IMO. No deciding when to compile immediate words.
You simply never compile immediate words and so the complications around
that are gone. Nothing state-smart, so STATE doesn't need to be
explicit. (But you could provide a different cursor while compiling.) 

What do we lose? It doesn't provide an obvious way to replace
state-smart words. You could have two words with the same name and
arrange for different ones to be found first at different times, but
there's nothing here to say how to do that.

And you lose the chance to make control structures without parsing or
using the dictionary. With :NONAME and POSTPONE and COMPILE, you can
have a program that assembles Forth comands with no use of the
dictionary at all. Build a headerless definition, use postponed commands
to build control structures, lay down xt's with COMPILE, there doesn't
have to be anything at all to look up in the dictionary. I don't know
how often that's im****tant, but it's something we'd be losing.

And maybe something I've missed.

> > If you want it to do different things then instead of using STATE it
> > might as well be two words.
> 
> > In terms of traditional implementations, if you get rid of the
> > immediate header bit then as Bruce pointed out you have 8 categories
> > available.  HOST COMPILER TARGET etc could fit in there, or others.
> 
> Urgh.  That sounds even more complicated than what we have now.  :-(

If you want to have a host-target system that fits the proto target
standard, there's nothing particularly wrong with doing it this way. I
think. I don't see that it would be better to do it with wordlists. If
you need 5 categories that are kind of like wordlists and you have 3
bits available, that still gives you 3 more categories. If you wanted
you could even have one of them be SMUDGE . :)