Finding Forth host type
Brad
platform its being loaded onto, so that it can decide which way to do
things the TC didn't think of.
An environment variable for that would be nice -- is it included in
Forth 200x (better make that 201x)?
-Brad
Josh Grams
<842a6e5c-2005-4bf2...@g31g2000vbr.googlegroups.com>
Nope. Some systems do have an environment query, but none of them use
the same one. And many systems don't make any provision for detecting
which system or version at all.
So basically it's a royal pain. :)
Here's my current code. Where possible, I have used an environment
query. Otherwise I check for the existence of a word, trying to pick
one which is likely to be (and remain) unique to each system.
--Josh
compat.f
------------------------------------------------------------------------
\ Detect forth system and use appropriate prelude.
\ Currently detects:
\ ciforth - http://home.hccnet.nl/a.w.m.van.der.horst/ciforth.html
\ FICL - http://ficl.sourceforge.net/
\ Gforth - http://www.jwdt.com/~paysan/gforth.html
\ kForth - http://ccreweb.org/software/kforth/kforth.html
\ PFE - http://pfe.sourceforge.net/
\ pForth - http://www.softsynth.com/pforth/
\ SP-Forth - http://spf.sourceforge.net/
\ Win32Forth - http://win32forth.sourceforge.net/
\ Other systems to consider (most of these aren't standard):
\ 4p - http://maschenwerk.de/
\ bigFORTH - http://www.jwdt.com/~paysan/bigforth.html
\ dsForth - http://www.delosoft.com/
\ FINA - http://code.google.com/p/fina-forth/
\ hForth - http://www.taygeta.com/hforth.html
\ IsForth - http://isforth.com/
\ NTF/LXF - http://falth.homelinux.net/readme2.html
\ MinForth - http://home.arcor.de/a.s.kochenburger/minforth.html
\ RetroForth - http://retroforth.org/
\ Process rest of line only if FLAG is true
: uses ( flag -- ) 0= IF POSTPONE \ THEN ;
: ?? ( "name" -- flag ) BL WORD FIND SWAP DROP 0= 0= ;
?? ENVIRONMENT? 0= uses : ENVIRONMENT? 2DROP 0 ;
\ On ciforth, COMPARE is not loaded by default.
?? NIP 0= uses : NIP SWAP DROP ;
?? STR= 0= uses : MATCH? >R COUNT ROT COUNT ROT = R> AND ;
?? STR= 0= uses : (STR=) BEGIN DUP 0 > WHILE MATCH? 1- REPEAT 0= ;
?? STR= 0= uses : STR= ROT 2DUP = >R MIN (STR=) NIP NIP R> AND ;
: ciforth? ( -- flag )
S" NAME" ENVIRONMENT? DUP IF DROP
S" ciforth" STR=
THEN ;
: ficl? ( -- flag ) S" ficl-version" ENVIRONMENT? DUP IF NIP NIP THEN ;
: gforth? ( -- flag ) S" gforth" ENVIRONMENT? DUP IF NIP NIP THEN ;
: kforth? ( -- flag ) [ ?? NONDEFERRED ] LITERAL ;
: pfe? ( -- flag )
S" FORTH-NAME" ENVIRONMENT? DUP IF DROP
S" pfe" STR=
THEN ;
: pforth? ( -- flag ) [ ?? ::::loadp4th.fth ] LITERAL ;
: spf? ( -- flag )
S" FORTH-SYS" ENVIRONMENT? DUP IF DROP
S" SP-FORTH" STR=
THEN ;
: win32forth? ( -- flag ) S" WIN32FORTH" ENVIRONMENT? DUP IF DROP THEN ;
ciforth? uses S" compat/ciforth.f" INCLUDED
ficl? uses include compat/ficl.f
gforth? uses include compat/gforth.f
kforth? uses include compat/kforth.f
pfe? uses include compat/pfe.f
pforth? uses include compat/pforth.f
spf? uses S" compat/spf.f" INCLUDED
win32forth? uses include compat/win32forth.f
MarkWills
Hmmm... Good idea... Perhaps a standard word, which returns a
string...
PLATFORM? TYPE
GForth ok
If returning strings is a pain, then Forth system producers could be
each be awarded a Vendor code. This would have to be administered by a
committee of some sort.
0 = Unassigned
1 = Forth Inc
2 = MPE
3 = GForth
In addition, a word to return the version number would be nice...
VERSION? .
101 ok
The 101 should be divided by 10, to get 1.01 - solves issues with
Forths that don't have floating point...
Just a thought... The VERSION word exists in my Forth and works as
noted above.
Mark
The Beez'
> In addition, a word to return the version number would be nice...
>
> VERSION? .
> 101 ok
>
> The 101 should be divided by 10, to get 1.01 - solves issues with
> Forths that don't have floating point...
>
> Just a thought... The VERSION word exists in my Forth and works as
> noted above.
It is used primarily to distinguish between itself and other Forths,
like [DEFINED] 4TH# [IF]
But it returns the version number like your VERSION?
If it were to be a standard it would be trivial to define an alias.
Hans Bezemer
Bernd Paysan
> Hmmm... Good idea... Perhaps a standard word, which returns a
> string...
>
> PLATFORM? TYPE
> GForth ok
>
> If returning strings is a pain, then Forth system producers could be
> each be awarded a Vendor code. This would have to be administered by a
> committee of some sort.
>
> 0 = Unassigned
> 1 = Forth Inc
> 2 = MPE
> 3 = GForth
>
> In addition, a word to return the version number would be nice...
>
> VERSION? .
> 101 ok
>
> The 101 should be divided by 10, to get 1.01 - solves issues with
> Forths that don't have floating point...
>
> Just a thought... The VERSION word exists in my Forth and works as
> noted above.
Gforth and bigForth use an environment query with the name of the Forth
system - it returns the version number (in Gforth as string, in bigForth
as double number, not fully consistent ;-).
VFX Forth has a noop word called VFXFORTH. bigForth has the same,
introduced when I ported MINOS to VFX (it's easier to say [IFDEF]
bigforth, as to do the environment query).
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
David N. Williams
> Brad wrote:
> <842a6e5c-2005-4bf2...@g31g2000vbr.googlegroups.com>
>> I would like a portable way for an ANS program to distinguish which
>> platform its being loaded onto, so that it can decide which way to do
>> things the TC didn't think of.
>>
>> An environment variable for that would be nice -- is it included in
>> Forth 200x (better make that 201x)?
>
> Nope. Some systems do have an environment query, but none of them use
> the same one. And many systems don't make any provision for detecting
> which system or version at all.
>
> So basically it's a royal pain. :)
>
> Here's my current code. Where possible, I have used an environment
> query. Otherwise I check for the existence of a word, trying to pick
> one which is likely to be (and remain) unique to each system.
> compat.f
> [...]
> ciforth? uses S" compat/ciforth.f" INCLUDED
> ficl? uses include compat/ficl.f
> gforth? uses include compat/gforth.f
> kforth? uses include compat/kforth.f
> pfe? uses include compat/pfe.f
> pforth? uses include compat/pforth.f
> spf? uses S" compat/spf.f" INCLUDED
> win32forth? uses include compat/win32forth.f
Thanks for posting this!
Even if there were a Forth 200x environment variable, wouldn't
we need something like the above *? words? I.e., it appears
there would need to be some sort of "official" data base as
well.
-- David
Bruce McFarling
> Hmmm... Good idea... Perhaps a standard word, which returns a
> string...
> PLATFORM? TYPE
> GForth ok
A library could define a constant for each platform:
TRUE CONSTANT gforth.model
... used with words like ...
: model? ( "modelname" -- flag )
BL WORD FIND IF EXECUTE ELSE DROP FALSE THEN ;
model? gforth.model [IF] ...
> If returning strings is a pain, then Forth system producers could be
> each be awarded a Vendor code. This would have to be administered by a
> committee of some sort.
> 0 = Unassigned
> 1 = Forth Inc
> 2 = MPE
> 3 = GForth
> In addition, a word to return the version number would be nice...
the model? word works for version constants ... and assigning model
names would be easier than assigning Vendor Codes, since the name of
the implementation could be used as the basis, and the version coding
of the system as well.
model? gforth.0.8 [IF] ...
Ed
Several forths include such an environment variable. However
its usefulness in a Standard context is doubtful.
Whatever non-Standard code you write using the platform
variable will be subject to obsolescence. What worked this
week, may no longer work next week if the forth is updated.
The beauty of a Standard Program is that it is largely independent
of the forth on which it is run. Furthermore, anyone can maintain
it. Adding compiler-dependencies would defeat this.
Albert van der Horst
MarkWills <markrob...@yahoo.co.uk> wrote:
>On Jan 6, 10:58=A0pm, Brad <hwfw...@gmail.com> wrote:
>> I would like a portable way for an ANS program to distinguish which
>> platform its being loaded onto, so that it can decide which way to do
>> things the TC didn't think of.
>>
>> An environment variable for that would be nice -- is it included in
>> Forth 200x (better make that 201x)?
>>
>> -Brad
>
>Hmmm... Good idea... Perhaps a standard word, which returns a
>string...
>
>PLATFORM? TYPE
>GForth ok
>
>If returning strings is a pain, then Forth system producers could be
>each be awarded a Vendor code. This would have to be administered by a
>committee of some sort.
>
>1 =3D Forth Inc
>2 =3D MPE
>3 =3D GForth
Good lord ... Another point to discuss on the crowded meeting of
Forth vendors. ;-)
>
>In addition, a word to return the version number would be nice...
>
>VERSION? .
>101 ok
>
>The 101 should be divided by 10, to get 1.01 - solves issues with
>Forths that don't have floating point...
>
>Just a thought... The VERSION word exists in my Forth and works as
>noted above.
Yet another proposal every implementor had to agree on.
I really must insist that my proposal is the most sensible
(from 10 years ago)
ENVIRNOMENT strings:
NAME : name of the Forth
VERSION : version of the Forth.
As checking the version is done in a section specific
to the Forth, there need not be much convention about VERSION.
But I greatly prefer it to be a string.
PLATFORM is not a good query. I would expect it to
contain WINDOWS7 LINUX-SUSE or some such.
>
>Mark
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Bruce McFarling
> Brad wrote:
> > I would like a portable way for an ANS program to distinguish which
> > platform its being loaded onto, so that it can decide which way to do
> > things the TC didn't think of.
> > An environment variable for that would be nice -- is it included in
> > Forth 200x (better make that 201x)?
> Several forths include such an environment variable. However
> its usefulness in a Standard context is doubtful.
> Whatever non-Standard code you write using the platform
> variable will be subject to obsolescence. What worked this
> week, may no longer work next week if the forth is updated.
Yes. What this kind of word is used for by standard code is to load an
implementation specific prelude file to add those capabilities needed
by the application that are not available under the standard (and,
optionally, to take advantage of an implementation specific feature to
provide a more efficient version of one of the support words).
This is why it does not need to be in the standard as such. A single
implementation specific file can *define* the model constant (or
constants, if the application file has some "family" preludes such as
the broad au=char=byte family), and then the portable source can *use*
those model constants to determine which prelude file to load when.
And, of course, the "load and run" package for each system is just
packaged to first include the appropriate implementation/system
specific load constant defining file.
> The beauty of a Standard Program is that it is largely independent
> of the forth on which it is run. Furthermore, anyone can maintain
> it. Adding compiler-dependencies would defeat this.
This informs my "3 level" strategy for a rudimentary library oversight
system:
(1) in level one, ".fs" files just assume that whatever standard words
that they need are available, that they are defining into the right
vocabulary, and that whatever additional application specific features
they require are available. They do no vocabulary management, no file
management, no conditional compilation. Also at level one are
implementation and system specific files, prefixed by a three letter
implementation/system code.
(2) in level two, ".nfs" files know about the vocabularies they are
building and the ones they are using, test for the presence of what is
needed and conditionally load additional features from the filesystem
namespace in which they are found, and install version constants.
(3) in level three, ".nlf" files know about the file structure of the
library collection and the version dependencies and implementation
dependencies of their ".nfs" files.
The rationale is twofold. First, it supports an incremental approach
to portabilities, where an application built for one system has two or
more files, a load file, a main definition file, and whatever
supporting toolkit files they are using. Someone porting it to another
system will find some implementation dependencies, split the main
definition file(s) into a portable part and an implementation specific
portability harness, and add a little logic to the load file to select
which portability harness is required. And, finally, someone looking
to add that to a library (whether portable, targeting an
implementation across various systems or a system with various
implementations, or supporting a specific implementation) organizes
the files into the library file hierarchy, possibly does some
replacement of the support facilities with the facilities already
present in the library, and write the main library load file.
Second, and more importantly, the system encourages placing as much
program logic as possible into common portable definition files, which
therefore get exercised in the widest variety of settings, which
therefore bring bugs to light for getting them fixed.
Brad
>
> Hmmm... Good idea... Perhaps a standard word, which returns a
> string...
>
> PLATFORM? TYPE
> GForth ok
>
That's almost a filename, suitable for use by INCLUDED.
Bruce McFarling
Or a pathname, suitable for use by F" GForth/prelude.fs" INCLUDED
idknow
wrote:
> In article <a6880c66-825e-4fe6-882a-abc862825...@e27g2000yqd.googlegroups.com>,
>
>
>
> MarkWills <markrobertwi...@yahoo.co.uk> wrote:
> >On Jan 6, 10:58=A0pm, Brad <hwfw...@gmail.com> wrote:
>
> Good lord ... Another point to discuss on the crowded meeting of
> Forth vendors. ;-)
>
>
>
> >In addition, a word to return the version number would be nice...
>
> >VERSION? .
> >101 ok
>
> >The 101 should be divided by 10, to get 1.01 - solves issues with
> >Forths that don't have floating point...
>
> >Just a thought... The VERSION word exists in my Forth and works as
> >noted above.
>
> Yet another proposal every implementor had to agree on.
>
> I really must insist that my proposal is the most sensible
> (from 10 years ago)
> ENVIRNOMENT strings:
>
> NAME : name of the Forth
> VERSION : version of the Forth.
Hello, folks.
As in the words of some language text, using "NAME" and "VERSION"
would muck up the namespace.
and in that vein, I haven't read a discussion of separate lexicons or
dictionaries ala Fig-forth/F83 lately; is no-one implementing them?
Also, has anyone given thought to $PATH-style searching implemented
along lexicons? This would lead to inheritence and encapsulation.
The only issue I cant surmount is whether or not to somehow mark a
word that is not in the $path (same when wanting a usr/bin tool
instead of one that is in /bin or ~/ )
Thanks for the discussions.
Anton Ertl
>Gforth and bigForth use an environment query with the name of the Forth
>system - it returns the version number (in Gforth as string, in bigForth
>as double number, not fully consistent ;-).
Given that these version numbers are uncomparable between systems,
consistency would buy nothing. Likewise, having a standardized query
for the system name would buy relatively little. The typical use of
such a standardized query would be something like:
s" forth-system" environment? [if]
2dup s" gforth" compare 0= [if]
2drop ...
[else] 2dup s" bigforth" compare 0= [if]
2drop ...
With the individual queries you can write
s" gforth" environment? [if]
2drop ...
[else] s" bigforth" environment? [if]
2drop ...
The latter is actually simpler.
The only advantage of such a FORTH-SYSTEM query would be if you had
some names somewhere that match the resulting names, e.g.:
s" forth-system" environment? [if] included [then]
However, you will probably want to manipulate the file name first and
also provide better protection against systems with other names and
systems that return false to such a query.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2009: http://www.euroforth.org/ef09/
Albert van der Horst
idknow <idk...@gmail.com> wrote:
>On Jan 8, 8:11=A0am, Albert van der Horst <alb...@spenarnc.xs4all.nl>
>wrote:
>> In article <a6880c66-825e-4fe6-882a-abc862825...@e27g2000yqd.googlegroups=
>.com>,
>>
>>
>>
>> MarkWills =A0<markrobertwi...@yahoo.co.uk> wrote:>> Good lord ... =A0Another point to discuss on the crowded meeting of
>> Forth vendors. =A0;-)
>>
>>
>>
>> >In addition, a word to return the version number would be nice...
>>
>> >VERSION? .
>> >101 ok
>>
>> >The 101 should be divided by 10, to get 1.01 - solves issues with
>> >Forths that don't have floating point...
>>
>> >Just a thought... The VERSION word exists in my Forth and works as
>> >noted above.
>>
>> Yet another proposal every implementor had to agree on.
>>
>> I really must insist that my proposal is the most sensible
>> (from 10 years ago)
>> ENVIRNOMENT strings:
>>
>> =A0 =A0 =A0 =A0 VERSION : version of the Forth.
>> [snipd]
>Hello, folks.
>
>As in the words of some language text, using "NAME" and "VERSION"
>would muck up the namespace.
>
>and in that vein, I haven't read a discussion of separate lexicons or
>dictionaries ala Fig-forth/F83 lately; is no-one implementing them?
All Forth's I know of, implement queries in the sense of
ENVIRONMENT? by a separate wordlist.
E.g. in lina/wina it is created by `` NAMESPACE ENVIRONMENT ''.
' ENVIRONMENT >WID gives the wid of that wordlist.
>
>Also, has anyone given thought to $PATH-style searching implemented
>along lexicons? This would lead to inheritence and encapsulation.
>The only issue I cant surmount is whether or not to somehow mark a
>word that is not in the $path (same when wanting a usr/bin tool
>instead of one that is in /bin or ~/ )
Well, well. That would not chime with the wid oriented approach.
Or you could say that it is implemented already.
>
>Thanks for the discussions.
Bruce McFarling
> and in that vein, I haven't read a discussion of separate lexicons or
> dictionaries ala Fig-forth/F83 lately; is no-one implementing them?
I don't understand the question: doesn't every Forth-94 implementation
that supports the SEARCH words support separate lexicons? It seems to
me that portable object-oriented programming systems rely on SEARCH
for namespace control.
> Also, has anyone given thought to $PATH-style searching implemented
> along lexicons? This would lead to inheritence and encapsulation.
> The only issue I cant surmount is whether or not to somehow mark a
> word that is not in the $path (same when wanting a usr/bin tool
> instead of one that is in /bin or ~/ )
Its straightforward to set up the search order to define a path and
then store it compactly as a list of wid's. When you establish a new
search order, you declare the path first ... eg,
[]Path[] ALSO []New[]
... but of course the portable size of the path plus current search
vocabulary is eight items, and for people who use vocabularies who
want a particular application launch word available generically, its
more common to define the application launch word into ``FORTH-
WORDLIST''.
idknow
Well, since that "static" 8-element vector for holding the search-path
was first developed, I've always considered a contrived upper limit
that turned my stomach.
I recall that Fig forth on the Apple ][, supporting an unlimited
number of vocabularies, could search them all for a word in a
reasonable amount of time. I frankly don't comprehend why a stack (or
array) was used instead.
As I see it, vocabularies as implemented in Fig forth and its `Find'
word can easily implement both encapsulation and data-hiding because
searching begins at `Current' and then ascends to parent when not
found.
Thus with a new vocabulary below another, a word not in Current would
cause Find to search other vocabularies that are parent or sibling to
Current.
If I'm not mistaken, in Forth-94 and newer standards, wordlists are
global, aren't they? Using the Vocabulary's word-name (the PFA[]) as
a vector (it's not really an actual executable word) to hold relevant
word-list information would allow for local (non-global) use (or both,
global and local)
That is, in a lexicon's word-name, a subordinate vocabulary, the
vectors in the PFA of the word would have pointers to parent-lexicon,
last-defined-word, (maybe the) first defined-word, and perhaps, a
pointer to any sibling lexicons.
In the last paragraph, "subordinate" would refer to all vocabularies
that branch off the main Forth list, and vocs that are connected to
those and so on.
Thanks for the response.
J Thomas
> Well, since that "static" 8-element vector for holding the search-path
> was first developed, I've always considered a contrived upper limit that
> turned my stomach.
>
> I recall that Fig forth on the Apple ][, supporting an unlimited number
> of vocabularies, could search them all for a word in a reasonable amount
> of time. I frankly don't comprehend why a stack (or array) was used
> instead.
Here's how it looks to me: Back then there were some Forth systems that
allowed a limited number of vocabularies. And they didn't want the
standard to require them to quit that. The standard would have to either
set some limit for the number of wordlists or else the implication would
be that it should be unlimited to the extent of available memory etc. So
they did set a reasonable limit, 8 wordlists.
It's fine for Forth systems to allow more wordlists, to allow an unlimited
number, and many (most?) do. If your program depends on that then it won't
run right on the systems that don't provide enough wordlists. That means
it has an "environmental dependency". In theory you are supposed to
provide documentation that says how many wordlists you need, and it's OK
to say you need an indefinite number. You still have a standard program,
it's just a standard program with an environmental dependency. The
standard systems that provide more than 8 wordlists are all standard
systems, no problem. All's right with the world except that Forth systems
that provide only 8 wordlists at a time can be labeled standard too and
your program won't run on them.
Bruce McFarling
> Well, since that "static" 8-element vector for holding the search-path
> was first developed, I've always considered a contrived upper limit
> that turned my stomach.
Then, since most PC-host Forth's permit a much larger or indefinite
number, declare a dependency on 256 or whatever.
For my purposes, I have no trouble with the limit. The system wordlist
on a constrainted system normally takes one slot or two, depending on
whether the minimal wordlist is Forth itself, one for the library
oversight system, which will have accumulated any standard words not
in the host FORTH-WORDLIST, one promiscuously shared tools wordlist,
one to three support toolkits being used at the moment, and one for
the CONTEXT.
> I recall that Fig forth on the Apple ][, supporting an unlimited
> number of vocabularies, could search them all for a word in a
> reasonable amount of time. I frankly don't comprehend why a stack (or
> array) was used instead.
AFAIU, for providing a portable way to re-order the search path,
rather than have the search path implied by the vocabulary into which
a vocabulary is defined.
> As I see it, vocabularies as implemented in Fig forth and its `Find'
> word can easily implement both encapsulation and data-hiding because
> searching begins at `Current' and then ascends to parent when not
> found.
> Thus with a new vocabulary below another, a word not in Current would
> cause Find to search other vocabularies that are parent or sibling to
> Current.
Precisely, an inflexible pre-defined search path, the opposite of:
> ... $PATH-style searching implemented along lexicons?
> If I'm not mistaken, in Forth-94 and newer standards, wordlists are
> global, aren't they?
> Using the Vocabulary's word-name (the PFA[]) as a vector (it's not really
> an actual executable word) to hold relevant word-list information would
> allow for local (non-global) use (or both, global and local)
So, for example (without semantic sugar to focus on the mechanism -
you'd, obviously write a CREATE DOES> word to automate what I am doing
manually here)
ONLY FORTH DEFINITIONS
WORDLIST CREATE FOO1 ,
WORDLIST CREATE FOO2 ,
GET-ORDER FOO1 @ SWAP 1+ SET-ORDER DEFINITIONS
WORDLIST CREATE BAR ,
ONLY FORTH
GET-ORDER FOO2 @ SWAP 1+ SET-ORDER DEFINITIONS
WORDLIST CREATE BAR ,
ONLY FORTH
WORDLIST CREATE BAR ,
You have three wordlist's ``BAR'', one when only FORTH is present, one
when FOO1 is first in the search order, one when FOO2 is first in the
search order.
So the wordlists are as global or as local as you want them to be.
Indeed, if you define a one-off wordlist which is only stored in a
word that performs the search on that wordlist, they can be in effect
local to a single word.
> That is, in a lexicon's word-name, a subordinate vocabulary, the
> vectors in the PFA of the word would have pointers to parent-lexicon,
> last-defined-word, (maybe the) first defined-word, and perhaps, a
> pointer to any sibling lexicons.
You can certainly do that with WORDLISTs if you wish, though I would
assume that pointers would be whatever it is you get when you do ... '
>BODY ... in your creating word. PFA is an implementation-specific
concept.
> In the last paragraph, "subordinate" would refer to all vocabularies
> that branch off the main Forth list, and vocs that are connected to
> those and so on.
Yes, you certainly can generate a hierarchy along those lines,
portably, with WORDLIST and the SEARCH wordset. If you have a deep
hierarchy, you'll have an implementation dependency on the size of the
search stack, but in the kind of resource-constrained system where the
search stack size is likely to be binding, there's not likely to be a
need for more than four or five lexicons open at any one time, and of
course with the ONLY FORTH ALSO system, you can nest arbitrarily deep
while only using one slot in the search stack:
ONLY FORTH ALSO []Root /sub1 /sub2 /sub3 child[]
... would have FORTH-WORDLIST in the search order, then add []Root and
(assuming they are all created as Forth-83 style vocabularies) REPLACE
[]Root with /sub1, sub2, sub3, and child[] in turn. It does not
consume a search slot for each descent down a hierarchy.