Most systems have an alphabet soup of words in the FORTH wordlist.
Users without intimate knowledge of the ANS Forth standard have a
tendency to use the words available to them, which includes many non-
standard (even if traditional) words. This hampers portability. It
would be very helpful to be able to explicitly set the search order.
For example:

WORDLIST CONSTANT MyWords
CORE CORE-EXT MyWords 3 SET-ORDER
MyWords SET-CURRENT
\ My Code Here...

If the application compiles without complaint, the specified wordlists
were sufficient for the application. Fortunately, such functionality
can be added with ANS Forth code. For example, a wordlist called CORE
can be created and filled with aliases. Some of the above wordiness
could be tidied up:

: WORDLIST: ( -- ) WORDLIST CONSTANT ;
: ORDER[ ( ... <]> -- ) ( code to set order and
current ) ;

Which reduces the preamble to:

On Dec 20, 8:23 am, Brad Eckert tinyboot.com> wrote:

I think so. ROOT would contain FORTH, CORE, CORE-EXT, WORDLIST:, etc.
WORDLIST: would place all new wordlists in ROOT.

VISIBILITY: would be a better name than ORDER[. Maybe it should change
the search order to ROOT before parsing the wordlist names, add ROOT,
then add each wordlist to the search order as it is encountered.

Brad

On Dec 20, 10:54 am, Brad Eckert tinyboot.com> wrote:

There is a third alternative, which is to include them in ONLY.

VISIBLE:

would be a better name than VISIBILITY: ... its shorter, and says more
explicitly what is being done.

Brad Eckert tinyboot.com> writes:

An alternative is to have a tool that reports what words were used
from what wordset. Gforth includes such a tool: ans-report.fs. If
the program is intended to be fully standard compliant, porting to
Gforth should be trivial, or at least a job that has to be done
anyway.

Another alternative is iForth's warnings about non-ANS words.

The problem with the wordlist and search order approach is that, if
the application sets the search order itself, e.g., with ONLY FORTH,
the check for standard words will be silently disabled.

On Dec 22, 12:40 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:

While silent, its not all that invisible if its in the same file that
sets the search order using this approach. However, it would be if the
application INCLUDEs a wordlist from a library that itself sets the
search order.

AFAICS, that's kind of OK, as long as ONLY is implemented as a
distinct "root" vocabulary ... for one thing, its up to the library of
wordlists to document their dependencies, and for another, its easy
enough to define a MARKER into ONLY and then define FORTH and ALSO
words into ONLY that print a warning. Then its not silent anymore.