15.6.2.2534 [UNDEFINED] bracket-undefined TOOLS EXT
Compilation:
Execution:
Skip leading space delimiters. Parse name delimited by a space. Return a false flag if name is the name of a word that can be found (according to the rules in the system's FIND); otherwise return a true flag. [UNDEFINED] is an immediate word.
Implementation:
ContributeContributions
EricBlake
[406] Is behavior ambiguous if a name cannot be parsed?Request for clarification2025-08-20 12:49:54
In my single-xt Forth implementation, my initial code for [UNDEFINED] reused code for ', and as a result,
: a S" [UNDEFINED]" EVALUATE ; a
resulted in -16 throw (attempt to use zero-length name) rather than pushing TRUE to the stack. But when I compared with gforth, I noticed that gforth throws -16 for ' but happily returns TRUE for [UNDEFINED] on a zero-length name when input is exhausted. Similarly, SwiftForth returns TRUE for [UNDEFINED] while leaving the stack empty after bare '; inspecting further sees that ' ' catch leaves -2 on the stack (but the only indication that ' on a line by itself tried to abort" is that the prompt is ? rather than ok; no useful message appears, and not the -16 that gforth produces); while ' [undefined] catch leaves -1 0 on the stack. Does the standard already include this in the realms of ambiguous behavior, or is supporting the use of [UNDEFINED] at the end of the input buffer on a zero-length name common enough practice to be a bug in my implementation, even though such a name cannot be ticked? It's already clear that the future FIND-NAME should allow a search for a zero-length name rather than throw, https://forth-standard.org/proposals/find-name#reply-1481, but that's because FIND-NAME is not a parsing word, and it is a different matter to supply an explicit zero-length string as an argument than it is to encounter end-of-input-buffer in a parsing word. This becomes more relevant when considering that a future standard is likely to require more consistency on when particular throw conditions occur, rather than leaving behavior ambiguous: https://github.com/ForthHub/standard-evolution/issues/2
ruv
I would treat the example is ambiguous.
The section 4.1.2 Ambiguous conditions says that an ambiguous condition can occur due to "unexpected end of input buffer, resulting in an attempt to use a zero-length string as a name". And in turn, on an ambiguous condition, any behavior is allowed (3.4.4).
Thus, different Forth systems may exhibit different behavior. And both of the actions mentioned — returning a flag and throwing an exception — are standard compliant.
I think in the future we should stick to throwing -16 in this case, or, better, introduce a new throw code "unexpected end of input buffer" that can be used for s", [char], and other words as well.
AntonErtl
The standard does not state that this is an ambiguous condition for this word, but using [UNDEFINED] without a name is most likely a programming mistake rather than intentional, so I think that this may be something we might fix in the future if we ever get around to it.