Extension queries

[ RfDs/CfVs | Other proposals ]

Problem

How does a program know whether the system it runs on supports one of the extensions that ran through the RfD/CfV process, so that the program can implement the extension itself or work around its absence?

Proposal

If the string passed to ENVIRONMENT? starts with "X:", ENVIRONMENT? returns false if the system does not implement the extension indicated by the query string in full, or if there is no such extension that has gone to a CfV.

For an extension from the list of CfVs, take the linked-to filename, delete the ".html", and prepend "X:" to construct a query string for the extension.

If the system implements the extension, ENVIRONMENT? may return true (without additional values) or false.

Typical Use

S" X:deferred" ENVIRONMENT? 0= [IF]
... \ reference implementation of the deferred words proposal
[THEN]

Remarks

Why allow returning false when the system supports the extension?
Returning false when the system supports the extension will usually be safer than returning true when the system does not support the extension; in the former case the program will be slower, or have degraded features; in the latter case the program will usually fail in unpredictable ways.

Therefore, systems must not return true for extensions that have not yet gone to a CfV (the proposal for the extension could still change).

So, if a system happens to already support the extension, it will have to report false on queries for the extension at least from the time when the proposal goes to a CfV until the time that an update of the system with updated extension queries is released.

Moreover (and possibly more importantly), this feature means that systems whose implementors have never heard of (or ignore) RfDs and CfVs will work correctly for extension queries (as long as they don't support any queries starting with "X:" on their own), so a program written to cope with this specification will usually work correctly even on such systems.

Why not let ENVIRONMENT? return a flag and true, like for wordset queries?
This proposal is easier to use. What is the point of returning an extra flag? "Yes, we have heard of that extension, but no, we have not implemented it"? That's not a useful information to have; what should a program do with that information?
Why the "X:" prefix?
This will hopefully ensure that there is no naming conflict with any existing environmental query of any system; it also reserves a part of the environmental query name space (by requiring a false result for anything that has not gone to a CfV), without consuming all of it.

If you know of any name conflict of the "X:" prefix with an existing system and have a better suggestion for a prefix, let me know.

What about extension proposals that have not (yet) gone to a CfV?
If you want to introduce queries for them, do it with a different prefix.
Why not include extension proposals that have not (yet) gone to a CfV?
They may still change before they go to a CfV, so it would not be clear if the system and the querying program refer to the same proposal.
Implementation and Tests

Experience

All ANS Forth systems I know implement this proposal in a minimal way (answer all queries with false). None implement it in a non-minimal way. No programs have used the proposal yet.

Change history

Comments


Anton Ertl