15.6.2.1909.10 NAME>COMPILE name-to-compile TOOLS EXT

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.

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.

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

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.

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 ;

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?

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

Yes exactly!

S" ELSE" FIND-NAME ... NAME>COMPILE EXECUTE

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