Digest #33 2018-05-25
Contributions
If a system implements FIND, the xt returned by NAME>COMPILE should either be that of EXECUTE or that of COMPILE,; otherwise the result of FIND cannot represent the whole result of NAME>COMPILE. Given that, x is always another xt.
Maybe this should be added to the rationale of NAME>COMPILE.
When you post a reply, you easily get back to the reply with the submit button. If you press submit again, another copy of the reply is posted ... and again ... and again? A user should not be able to post the same reply twice while logged in.
Replies
A cmForth-like system could be standard by first looking up user-defined words, then (in compile state) the compiler words, then (in both states) the system-defined words. This does not allow to add new compiler words, but the standard does not allow that, either.
Concerning your description of NAME>COMPILE, optimization (set by SET-OPTIMIZER in Gforth or SET-COMPILER in VFX) affects COMPILE,, not NAME>COMPILE, so your second case does not exist. Otherwise yes, if we accept the present proposal, the xt2 produced by NAME>COMPILE ( nt -- xt1 xt2 ) has to be EXECUTE or COMPILE, to match this FIND; otherwise NAME>COMPILE would produce compilation tokens that cannot be represented by the results of FIND.
i think that's a bit backward. X is always a xt, but NAME>COMPILE can distinguish between optimising DCS and providing NDCS whereas FIND on its own can not.
In the former case, NAME>COMPILE produces xt special-compiler-xt and in the latter special-xt EXECUTE
So a compiler loop that performs NAME-COMPILE execute will produce optimised code without an intelligent compile, and optimisations can be declared using SET-COMPILER without marking the word immediate, just as if intelligent COMPILE, were in place. FIND for such a Forth would be non-optimising, but the semantics would, of course, be identical. FIND returns an immediate flag if NAME-COMPILE returns EXECUTE, and a default flag otherwise.
If we want to deprecate FIND, then this may be the way to go.
It's too early to rewrite FIND. It may be better to find an alternative and to mark FIND as obsolescent. Modern Forths have a range of flags other than IMMEDIATE, for example the NDCS flag. We have an opportunity to expose other flags and to replace xt value with xt mask where mask is a bitmask containing IMMEDIATE and NDCS bits. This gives more opportunities to systems. We also need to revisit COMPILE, and to provide a compiling word for words (e.g. IF and friends) that parse or produce/consume data at compile time. The standard's wording for compile time is mystically unclear.
It's too early to rewrite FIND. It may be better to find an alternative and to mark FIND as obsolescent. Modern Forths have a range of flags other than IMMEDIATE, for example the NDCS flag. We have an opportunity to expose other flags and to replace xt value with xt mask where mask is a bitmask containing IMMEDIATE and NDCS bits. This gives more opportunities to systems. We also need to revisit COMPILE, and to provide a compiling word for words (e.g. IF and friends) that parse or produce/consume data at compile time. The standard's wording for compile time is mystically unclear.
One benefit of this proposal is that it does not use "immediate" in a way that is at odds with the use in the rest of the document. AFAICT it also reflects the intent of the Forth-94 committee better than the current text. And 24 years after Forth-94, it is certainly not too early to make that clarification. It may be unnecessary, but there are people who make wide-reaching claims, because "immediate" is used here with a different meaning than in the rest of the document, so maybe such a clarification is necessary after all.
As for the alternative, I'll propose that Real Soon Now.
Yes, instead of COMPILE, there could also be a specialized word that is equivalent to COMPILE, for x. I don't see the point of putting optimization at that place (it looks just as expensive to implement as an intelligent COMPILE,), but yes, it can be done.
What would be problematic, however, and that's the point of my comment: if xt is neither equivalent to COMPILE, nor to EXECUTE.
I'm really not trying to stop people from improving FIND. I just need some breathing space to get to the next stage of VFX NDCS. This involves rebuilding the cross compiler on it, and it ain't pretty. Once that's done, I'll have a pretty good idea where the problems lie.
One of the problems in changing FIND now is the law of unintended consequences; basically what else are you going to damage? The safest course may well be to find a new word that we can agree on, and then to mark FIND as obsolescent.