Re: DISFAVORED Was: name for 3 PICK finally?

Bruce McFarling <agila61@[EMAIL PROTECTED]
> wrote:
> Jonah Thomas <jethom...@[EMAIL PROTECTED]
> wrote:

> I don't follow the distinction here between "macro" on one hand and
> "POSTPONE" on the other hand ... "POSTPONE lets you / macros don't let
> you".
> 
> The thing that POSTPONE sup****ts automatically that an early bound
> macro would have to go to more trouble to sup****t is state
> dependence ... making a decision of what to compile based on a test at
> the time of compilation.
> 
> But clearly, if the macro building word is early-bound, it doesn't
> require string parsing and dictionary look-ups when it executes. So it
> seems like you are making late-bound macros into the only kind of
> macros that exist.

My confusion came because I was thinking in terms of a late-binding
macro only. If that's all you have, you get some limitation.
 
> I normally write compiler macros using POSTPONE, and that's the only
> thing I use POSTPONE for. If an early-bound macro compiler was built
> into the implementation, I could relegate POSTPONE to a Forth-94
> ****tability harness.

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.

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. Redefine IF and the old IF is no longer available. Etc.
It's simpler but a little less flexible.