Proposal: Known undefined word XLERB

Is xlerb now trademarked by the owner of that internet domain? Do we now need UHO’s permission to use it in the standard?

<< joke! >>

For documentation purposes, running tests, and provoking exceptions there is a need for a word that is never in the dictionary.

When the search order is empty, no definition can be found. This can be used to provoke exceptions in test cases.

Overall, I like the idea of "XLERB", but I don't like the new formal requirements for systems and programs, and the ambiguous condition. I think, this can be specified using "should" instead of "shall".

As a counterexample, there is a more critical case: the standard does not specify that the system shall not define a word named "10". Then, why should it specify this for the name "XLERB"?

Another option for programs is to check if xlerb defined before run test cases:

[defined] xlerb [if] cr .( [warning, some tests cannot be run because `xlerb` is defined] ) cr [else]
\ run test cases
t{ ' ' catch xlerb -> -13 }t
t{ s" xlerb" find-name -> 0 }t
t{ 3 s" to xlerb" ' evaluate catch nip nip -> -13 }t
[then]

An argument against an ambiguous condition about the name "xlerb" is that word lists are sometimes used to store name-value pairs. It would be very unexpected and annoying if some specific name could never be placed to a wordlist.

It's indeed a good idea to warn if a word like 10 or 42 is defined (and the development Gforth does that). So far, while some Forth systems do print warnings, the standard doesn't talk about warnings. Warnings can always be switched off, e.g. with 0 warning ! in SwiftForth, or 0 warnings ! in Gforth, so when using a dictionary as key-value storage, you can just turn the warnings off when defining there. Technically, when a standard word prints a warning, it's behavior is outside the scope of the standard — it does something that's not specified, and there's e.g. no ambiguous condition for redefining a word that would allow a warning to be printed.

So there seems to be a need to talk about the concept of warnings.

How about NOTAWORD instead of XLERB ? Perhaps NOTAWORD is too obvious and not sufficiently geeky?

so when using a dictionary as key-value storage, you can just turn the warnings off when defining there.

If this word list is not included in the search order, Forth systems typically do not print any warning. And a standard-compliant program may use nonstandard warning or warnings only if it tests the Forth system vendor/version.

I see a problem only in the mentioned ambiguous condition, because it allows the system to throw an exception on such a word, and disallows a standard program to place such a word into any word list.

So there seems to be a need to talk about the concept of warnings.

Agreed.

It's indeed a good idea to warn if a word like 10 or 42 is defined

This still does not make a Forth system non-standard if it provides such words. Also, a Forth system may provide a word def, and then a standard program fragment hex def decimal constant foo will not work correctly on this standard Forth system. It is unclear how this problem can be formally solved.

The research of established practice showed that XLERB is already used for this purpose, while NOTAWORD isn't. The whole point of XLERB is that nobody other than the cat when walking over the keyboard will accidentally produce such a word. NOTAWORD could have a function like checking if a word is too short, too long, or contains non-graphical letters and in that case throw the appropriate error code.

FYI It appears that a domain name exists...

elf$ dig +short a XLERB.com
78.46.71.148
elf$ dig +short a XLERB.org
192.64.119.74
elf$ dig +short a XLERB.net
173.255.243.151