Proposal: Known undefined word XLERB

Informal

This page is dedicated to discussing this specific proposal

ContributeContributions

BerndPaysanavatar of BerndPaysan [368] Known undefined word XLERBProposal2024-11-25 22:50:28

Author:

Bernd Paysan

Change Log:

2024-11-25 initial version

Problem:

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

Solution:

Reserve XLERB as word that is not in the dictionary. An ambiguous condition exists if the user tries to define XLERB (a warning probably is sufficient). The name XLERB has been used in Starting Forth for this documentation purpose.

Typical use:

XLERB comic in Starting Fortn

T{ ' ' catch xlerb -> -13 }T
T{ s" xlerb" find-name -> 0 }T
: e-xlerb s" 3 to xlerb" evaluate ;
T{ ' e-xlerb catch -> -13 }T

Proposal:

Append the following text to 3.3.1.2:

Neither the system nor programs shall create a definition with the name XLERB, which is reserved for documentation and tests of well-known undefined definitions.

Append the following ambiguous condition to 4.1.2, after item 2:

  • The definition name is XLERB.

Reference implementation:

empty

Testing:

T{ ' ' catch xlerb -> -13 }T
T{ s" xlerb" find-name -> 0 }T
: e-xlerb s" 3 to xlerb" evaluate ;
T{ ' e-xlerb catch -> -13 }T

AndrewReadavatar of AndrewRead

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! >>

ruvavatar of ruv

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"?

ruvavatar of ruv

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]

ruvavatar of ruv

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.

BerndPaysanavatar of BerndPaysan

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.

MitchBradleyavatar of MitchBradley

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

ruvavatar of ruv

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.

BerndPaysanavatar of BerndPaysan

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.

achoweavatar of achowe

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
Reply New Version