Digest #59 2019-06-27
Contributions
requestClarification - The case of undefined interpretation semantics
By this specification, [DEFINED] word checks whether a name can be found according to the rules in the system's FIND.
1. According to "4.1.2 Ambiguous conditions", the definitions with undefined interpretation semantics may be not found by FIND in a standard Forth system. In this case [DEFINED] shall return false flag on such definition names. Is it correct?
2. If FIND throws an exception on such definitions (as possible action on an ambiguous condition), [DEFINED] shall throw the same exception as well. Is it correct?
3. As a consequence, a standard program shall not apply [DEFINED] on such definition names as IF, EXIT, COMPILE,, etc — since it is an ambiguous condition. Is it correct?
According to "4.1.2 Ambiguous conditions", a standard programme can't obtain the execution token of a definition with undefined interpretation semantics. So, it can't obtain xt of COMPILE, word by any means (according to the current specification for this word).
And the following code is not standard — without any solid reason:
: foo [ ' DUP COMPILE, ] ;
But the following code is standard:
: bar COMPILE, ;
: foo [ ' DUP bar ] ;
So, COMPILE, should be a regular word with single semantics (the execution semantics). But executing of this word when current definition was not started (by :NONAME or :, or other similar words if any) should be an ambiguous condition.
Replies
I don't remember how we came up with the name, but I think the idea was that, after processing the result with SUBSTITUTE, the % characters would not work as escapes, but be unchanged wrt the input to UNESCAPE.
IIRC we did not look at other languages when choosing this name. There was no Forth practice for UNESCAPE, and actually only single-vendor practice for SUBSTITUTE, but experiences with this kind of string processing in other contexts suggested that the SUBSTITUTE proposal was missing the UNESCAPE functionality.