Digest #32 2018-05-24
Contributions
Problem
The existing specification of FIND is unclear wrt what xts are returned under what conditions. It also uses a different notion of immediacy from the one in the Definition of Terms. From the rationale of FIND, it is obvious that cmForth inspired the idea that two different xts can be returned. The rationale of COMPILE, shows that the intention is that FIND can be usable for the user-defined text interpreter. But FIND as specified does not guarantee that. This proposal would fix this problem; it is also phrased in a way that includes systems like cmForth and Mark Humphries' system.
Proposal
Replace the text in the specification of FIND with:
Find the definition named in the counted string at c-addr. If the definition is not found, return c-addr and zero. If the definition is found, return xt 1 or xt -1. The returned values may differ between interpretation and compilation state. In interpretation state, EXECUTEing the returned xt performs the interpretation semantics of the word. In compilation state, the returned values represent the compilation semantics: if xt 1 is returned, then EXECUTEing xt performs the compilation semantics; if xt -1 is returned, then COMPILE,ing xt performs the compilation semantics.
Replies
The idea that IF ... ELSE ... THEN can morph to ELSE ... THEN is repulsive.
For [ELSE] ... [THEN] it's an artefact of the implementation. Implementation artefacts have no place in a standard.
It's a natural consequence of the spec, and slightly more elegant than the common 0 [IF] but it will break if you ever put an [IF] in front.
We (MPE) use [IF] and friends a great deal to configure cross-compiled targets. We noticed that [IF] ... [ELSE] ... [THEN] is unchecked, so we recently implemented a check at the end of each source file to see if we actually use it correctly. Oops! Lots of errors. So [ELSE] without [IF] is a total no no for us. It's amusing that it works, but let's just leave it that way.
Looks good to me, but the cmForth approach (of separate compilation and interpretation wordlists and searching one first) cannot be made Standard. It will not always find the most recent use of the name. Mark's doesn't either, but it fails by ignoring a more recent compile-only version while interpreting. Other Forths would attempt to execute the compile-only version, which would also be an error.
Thinking in terms of name tokens, it seems that NAME>COMPILE can take four possible forms:
xt compile, \ the default
xt optimiser, \ set by set-compile
xt execute \ a normal immediate word
ext execute. \ set by set-ndcs
FIND should return a flag of -1 for the first two cases (no optimisation is done unless with an intelligent COMPILE, that can derive the optimising xt from the original xt alone) and 1 in the other two cases, but the fourth only while compiling.