[ RfDs/CfVs | Other proposals ]
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?
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,
return true (without additional values) or false.
S" X:deferred" ENVIRONMENT? 0= [IF]
... \ reference implementation of the deferred words proposal
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
Therefore, systems must not return true for extensions that have
not yet gone to a CfV (the proposal for the extension could still
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
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
What about extension proposals that have not (yet) gone to a
If you want to introduce queries for them, do it with a different
Why not include extension proposals that have not (yet) gone to a
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
Implementation and Tests
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.