Re: DISFAVORED Was: name for 3 PICK finally?

On Mar 8, 8:02 pm, Jonah Thomas <jethom...@xxxxxxxxx> wrote:
Bruce McFarling <agil...@xxxxxxxxxxxx> wrote:

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, ....

I don't see any additional complexity there. You loop through a token
consuming process. You look up each token in the special wordlist, and
if its there, you do it. Otherwise, look up each token in the
dictionary, if its normal, compile the xt as a literal and then
compile ``COMPILE,'' ... if its immediate, compile the xt as a literal
and then compile ``EXECUTE''.

Its a different ``do-normal'', a different ``end$'', and a different
collection of words in the special wordlist (maybe just one), but it
is the very same tokenize and look-up loop as all of the wordlist and
version management words I am writing. The only complexity is
inherited from the rest of the system ... which suggests that if the
rest of the system enjoys an effective simplification, it would be
inherited by the macro compiler.

And to make that code you'd probably want to use POSTPONE IMMEDIATE etc.

If its Forth-94, there's no way to proceed without IMMEDIATE. However,
given the set of ...

: ; EXECUTE COMPILE, IMMEDIATE Next-Word and FIND (or the SEARCH
wordset)

.... POSTPONE could be dispensed with. The purpose of POSTPONE is to
allow a token to be postponed without finding out whether its
immediate or not, but if its an automated loop using the Forth-94
SEARCH-WORDLIST or FIND, then the information is automatically
available to the automated loop. And that also reduces the parsing
words.

Indeed, if the implementation has a non-parsing definition compiler
that is a factor of ":", then Next-Word ( -- ca u ) can be the sole
parsing word.

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 solution at the implementation level is to expose non-parsing
factors of all parsing words, so that every parsing word is in effect
defined as something like:

: CREATE ( "name" -- ) Next-Word CREATED ;

And advise users to build in non-parsing words, and then parse at the
top level if they wish.

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.

If there is an implementation that has immediate and non-immediate
words, and it exposes hooks to what it normally does with those in the
interpreter, then simply hanging the correct new responses in those
two cases is what is needed for a simple macro compiler.

In addition to that is a hook for a wordlist of special actions ...
which may be the wordlist Null-list in the default.

If the normal underlying compiler is simpler in some fundamental
way ... say, everything has an execution-xt and a compilation-token,
so compilation is a process of

``GET ( a -- xt a' ) @ ( -- xt compilation-token ) EXECUTE''

then the macro compiler is similarly simplified so that it no longer
has two cases, but only one case:

``GET LITERAL @ LITERAL `EXECUTE COMPILE,''

and if it is provided by accessing a provided hook, there is no longer
any need for a ``do-normal'' and ``do-immediate'', but only a ``do-
normal''.

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?

Its Forth. It does ITS job, which is to evaluate a string when the
macro is executed. And the basic syntax that emerges from the easiest
way to do it without getting caught in "how do I escape the quote?" is
quite expressive in the most normal case, where " is used, while clear
enough when " appears in the expression and there is a different quote
character ... | / and ~ all three work well, visually.

Sometimes that's the job you want done, sometime its not. Use it when
you want to do that job, and use something else when you want
something else.
.

Relevant Pages

  • Re: Open stack and colon definitions as a features (was: Of course it IS!!!)
    ... forth and macro. ... execute at compile time like immediate words did thirty years ... They do something more like change the system's STATE to execute ... the only thing I know is that it uses colors to specify ...
    (comp.lang.forth)
  • Re: Open stack and colon definitions as a features (was: Of course it IS!!!)
    ... execute at compile time like immediate words did thirty years ... So now we also know what color a macro has: ... In Chuck's colorforth green is more like "]" and yellow is ... They do something more like change the system's STATE to execute ...
    (comp.lang.forth)
  • Re: question about eval
    ... but the point is that we may not know at compile time what the ... This last part requires a macro, call it select, ... > time, to execute. ... > established in the surrounding lexical context. ...
    (comp.lang.lisp)
  • DISFAVORED Was: name for 3 PICK finally?
    ... I'd nominate IMMEDIATE. ... I wouldn't mind having a MACRO: ... No need for [COMPILE] POSTPONE etc. ... execute it by executing the macro. ...
    (comp.lang.forth)
  • Re: DISFAVORED Was: name for 3 PICK finally?
    ... Early-binding macro might be easy ... complexity is reduced by reducing the phases of execution to keep ... xt LITERAL COMPILE, xt LITERAL COMPILE, xt LITERAL EXECUTE xt ... out of existing parsing words, it's easy to get mixed up about when the ...
    (comp.lang.forth)