NAME>COMPILE name-to-compile TOOLS EXT

( nt -- x xt )

x xt represents the compilation semantics of the word nt. The returned xt has the stack effect ( i * x x -- j * x ). Executing xt consumes x and performs the compilation semantics of the word represented by nt.



In a traditional xt+immediate-flag system, the x xt returned by NAME>COMPILE is typically xt1 xt2, where xt1 is the xt of the word under consideration, and xt2 is the xt of EXECUTE (for immediate words) or COMPILE, (for words with default compilation semantics).

If you want to POSTPONE nt, you can do so with



AntonErtlavatar of AntonErtl [56] NAME>COMPILE resultComment2018-05-24 08:13:36

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.

JennyBrienavatar of JennyBrien

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.

AntonErtlavatar of AntonErtl

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.

JennyBrienavatar of JennyBrien

OK. If there's no advantage and no one does it, let's rule it out. The most important thing to come out of this long discussion, I think, is that there is a difference between providing an extra definition for default and non-default compiling semantics. The first needs a stack effect of xt -- , should be available to COMPILE, and returns a default flag in FIND. The second can have any stack picture, and returns an immediate flag in FIND. There has been much confusion because of the use of the latter approach, whether through STATE or dual xts, to optimise default semantics. You can't stop a user doing that, of course, but maybe a system shouldn't.

Optimising solely through COMPILE, makes things clearer. An word can then have both a NDCS and an optimised compilation of its interpretation semantics

JennyBrienavatar of JennyBrien

That does seem to imply that in any interface which sets a secondary NDCS xt, that xt should represent the whole of the compilation semantics.

AntonErtlavatar of AntonErtl

Yes, that would be the sub-xt ['] EXECUTE case. NAME>COMPILE could also return sub-xt ['] COMPILE,, but at least for the currently standardized dual-semantics words (S" S\" TO IS ACTION-OF), this would be wrong (COMPILE, must not parse).

It's not mandatory, though, only pretty compelling: One can think of clever ways to implement FIND in systems where NAME>COMPILE works differently, but AFAICS, these ways only increase complexity without offering an advantage, and there is a danger of introducing gotchas in corner cases.

Viewed differently: You have to have a find-comp-xt to be returned by FIND anyway, so you can just return it (and ['] EXECUTE or (unlikely) ['] COMPILE,) with NAME>COMPILE instead of returning something else. BTW, for a word X for which NAME>COMPILE would return something else, the find-comp-xt would be of the following word (and it would go with ['] EXECUTE):

:noname postpone X ;

ruvavatar of ruv

The returned xt has the stack effect ( i*x x -- j*x )

Where should these i*x come from?

Could somebody provide an example when i or j is greater than 0?

JennyBrienavatar of JennyBrien

Control words such as IF where the control stack is the data stack.

ruvavatar of ruv

Yes exactly!


This EXECUTE eventually (indirectly) executes the ELSE word that consumes and produces an orig token ( C: orig1 -- orig2 ) possibly on the data stack.

Reply New Version