Re: DISFAVORED Was: name for 3 PICK finally?

Bruce McFarling <agila61@[EMAIL PROTECTED]
> wrote:
> Jonah Thomas <jethom...@[EMAIL PROTECTED]
> wrote:
> > Yes. But what about transparency? The late-bound macro is easy to
> > understand. It does the same thing you'd get from EVALUATEing the
> > macro string later. It might not do what you'd most want it to, but
> > it's easy to see what it will do. Early-binding macro might be easy
> > to follow too. Choosing between them is less easy. Providing a way
> > to do either one and explaining the difference.... I dunno.
> 
> On the simple early binding macro ``[:] name macro_code [;]'',
> complexity is reduced by reducing the phases of execution to keep
> track of ... inside [ ... ] happens as you define the macro, and
> outside happens when the word containing the macro executes. The lack
> of flexibility (no way to modify what happens at macro run-time) is
> also lack of complexity.

It takes complexity to save xt's etc into a compiler macro. This is
system complexity.

To do it with standard code (as opposed to something efficient you do
under-the-hood), you'd wind up with something like:

.... xt LITERAL COMPILE, xt LITERAL COMPILE, xt LITERAL EXECUTE xt
LITERAL COMPILE, ....

And to make that code you'd probably want to use POSTPONE IMMEDIATE etc.
A lot of system complexity that could be left out. But that system
complexity doesn't bother users, much, right? No, sometimes it does.
Apart from users who make state-smart words, we get problems with
parsing words. these typically parse a string and do something to get a
result, then they compile the result so that at a later time pointers to
the result go onto the data stack. S" compiles a string literal and
later an address-and-count appear on the stack. ['] compiles an xt like
a literal and later the xt goes on the stack. Etc. The result is, when
you try to do something complicated about building a custom parsing word
out of existing parsing words, it's easy to get mixed up about when the
parsing happens and when the stuff is left on the stack. The deeper the
parsing words get embedded inside new parsing words, the easier it is to
get all that mixed up. The easiest way to avoid confusion is don't make
complex parsing words. The second-easiest way is to build your words a
layer at a time and test them at each step.

Still, it's easy to get into complications, and those complications are
automatically avoided if you leave out the complexities you get when you
sometimes compile immediate words. 

> The definition of MACRO due to Wil Baden is short enough that it shows
> that if you provide EVALUATE, you provide a late binding MACRO.

Exactly. It's extremely simple. And it does a lot of what you need,
without the complexity we're used to. But does it do enough of the job?
 
> > Still, you *could* have early-bound macros. They'd use methods that
> > I hope wouldn't be available to users, so that Forth would have an
> > extra layer of mystery, something extra beyond DOES> etc.
> 
> > I think you can get by with only late-binding macros, but it give
> > you limitations.
> 
> In a small free standing system where you might wish to be able to
> strip out headers, early-binding macros are the way to go. And if its
> got EVALUATE, a late binding ``macro:'' can always be loaded if
> desired.

If you want to strip out headers after all the compilation has been
done, then late-binding macros shouldn't cause a problem. If there are
no "special" words like IF THEN ." etc in the macro, then it doesn't
need to be a macro at all. Compile normal Forth words into a normal
definition and you won't miss the dictionary. So I don't think this will
usually be a problem.
 
> Like I said, ``[:] name macro_code [;]'' is not completely general,
> and in particular if you want to do a conditional at macro run-time,
> you have to fall back to POSTPONE. I normally don't want to do that,
> as it risks extending STATE dependency into a whole family of user-
> defined compiler state variable.

Yes. But simple text macros give you the problem that you might redefine
names that are used in them. That shouldn't be a problem for standard
words. If you redefine IF then it's your responsibility to watch out for
macros that use IF . But in large systems you don't know what might get
redefined by code you run without inspecting, and you don't know how the
search order might ge redefined. Anton and I think one or more others
pointed out problems with that.


OK, text macros are dead simple, but they don't fill enough of the need.