However, it does not seem that the capability of FORTH in SEARCH EXT
can necessarily be duplicated.
-1 SET-ORDER
and you are faced with whatever the system thinks is a minimal search-
order, with FORTH-WORDLIST and SET-ORDER is guaranteed to to be
available.
But you cannot necessarily *use* SET-ORDER to *bring* FORTH-WORDLIST
into the search order.
That is, (1) SET-ORDER needs a set of wordlists and a count.
(2) The only wordlist you can guarantee that you know about is FORTH-
WORDLIST
And (3) ``FORTH-WORDLIST 1 SET-ORDER'' is not guaranteed to work.
FORTH-WORDLIST has to provide the FORTH core when replacing the top of
the search order stack, but a system is not required to function with
nothing but FORTH-WORDLIST on the search-order stack. It is within its
rights to trap that as an error and abort.
And GET-ORDER is not guaranteed to be available, so you can't
necessarily do:
-1 SET-ORDER GET-ORDER FORTH-WORDLIST SWAP 1+ SET-ORDER
Of course, if you have FORTH from the SEARCH EXT wordset, and it
happens to be included in the minimal wordset from your
implementation ... well, then you are OK.
This is a bootstrapping trap-door, because intrinisically when you
drop down to the minimal search-order without knowledge of
implementation details, you are necessarily going to risk losing
access to everything you would normally use to boostrap around it ...
indeed, you are highly likely lose the ability to boostrap [UNDEFINED]
when in any minimal search order that is anything close to minimal.
You can't avoid the trapdoor by ticking GET-ORDER before reducing the
wordset, because EXECUTE is not guaranteed to be in the minimal search
order.
The bootstrap available is to try one thing, warning the user that it
might not work, and have alternatives available as \ comments to be
swapped around in a file editor, in case it fails as distributed.
Eliminating the trapdoor:
1. Adding FORTH to the minimal search order (gforth implements this)
2. FORTH-WORDLIST 1 SET-ORDER establishes the minimal search order
that includes FORTH-WORDLIST, even if that involves more things
underneath FORTH-WORDLIST to operate correctly
3. GET-ORDER is in the minimal search order.
If 1 or 2 is a preferable extension of the specification of SET-ORDER,
maybe that could be Forth200x.
Note that for 2, wherever ``FORTH-WORDLIST 1 SET-ORDER'' already works
and yields a functioning system with the Forth CORE, that is what it
should do ... the only change is extending SET-ORDER to convert
( forth-wordlist-wid 1 -- ) into the equivalent of that, in systems
where it presently creates an error state or error abort.
How did you get to that conclusion? A.16 does say that some systems
need pseudo-wordlists in the search order to be able to understand
numeric literals, but you don't need numeric literals to define FORTH
or
ALSO. So...I may be wrong, but I don't think that a standard system
should treat FORTH-WORDLIST 1 SET-ORDER as an error.
Also I don't see why you would get yourself in that situation in the
first place. Just define ONLY-FORTH or something, and use that
instead
of -1 SET-ORDER.
: ONLY-FORTH -1 SET-ORDER GET-ORDER FORTH-WORDLIST SWAP 1+ SET-ORDER ;
I can see that the standard might be a bit ambiguous, but I don't see
that it really matters.
Just my two cents,
--Josh
First, I ran it, and it was an error. Then I opened the dpANS pdf and
read the standard SEARCH words.
There is nothing in the specification of FORTH-WORDLIST or of SET-
ORDER that explicitly requires ``FORTH-WORDLIST 1 SET-ORDER'' to
function as I had expected, and FORTH-WORDLIST and SET-ORDER are the
only words required to be present when you:
``-1 SET-ORDER''.
That's how I reached that conclusion.
A.16 is probably why I expected it would work, but its not part of
specification. If that was the intention, Forth200x could make that
intention explicit.
> Also I don't see why you would get yourself in that situation in the
> first place. Just define ONLY-FORTH or something, and use that
> instead of -1 SET-ORDER.
What if ONLY and FORTH are not present? What would I define it with?
Its one thing if its a system that does not have a search order system
in place and one is being laid on top ... but if there is a search
order system in place, I'd want to use it.
It is, of course, no an insuperable difficulty ... its just one more
thing to add to the prefix file requirement, if there's no standard
portable way to do it.
Can I ask what Forth this is?
> There is nothing in the specification of FORTH-WORDLIST or of
> SET-ORDER that explicitly requires ``FORTH-WORDLIST 1
> SET-ORDER'' to function as I had expected...
I'd be inclined to take a less-inclusive view and say that since
the specification of SET-ORDER doesn't explicitly say that an
implementation may reject arbitrary search orders, or that you
have to base your search orders on an existing one instead of
passing whatever you want, that the behaviour you're seeing is
non-standard. But it doesn't really matter, since you want to
port to that system anyway...
>> Also I don't see why you would get yourself in that situation
>> in the first place. Just define ONLY-FORTH or something, and
>> use that instead of -1 SET-ORDER.
>
> What if ONLY and FORTH are not present?
As I said:
: ONLY-FORTH -1 SET-ORDER GET-ORDER FORTH-WORDLIST SWAP 1+ SET-ORDER ;
All those words are in CORE or SEARCH-ORDER, so if it's present
and you haven't yet changed the default search order or
compilation wordlist, then that should work just fine.
> It is, of course, not an insuperable difficulty ... it's just one
> more thing to add to the prefix file requirement, if there's no
> standard portable way to do it.
Sure, I'm just curious. I have this morbid fascination with the
quirks people come up with when they implement Forth systems...
--Josh
> >> How did you get to that conclusion? <SNIP> I may be wrong, but
> >> I don't think that a standard system should treat
> >> FORTH-WORDLIST 1 SET-ORDER as an error.
> > First, I ran it, and it was an error.
> Can I ask what Forth this is?
gforth 6.2
> > There is nothing in the specification of FORTH-WORDLIST or of
> > SET-ORDER that explicitly requires ``FORTH-WORDLIST 1
> > SET-ORDER'' to function as I had expected...
> I'd be inclined to take a less-inclusive view and say that since
> the specification of SET-ORDER doesn't explicitly say that an
> implementation may reject arbitrary search orders, or that you
> have to base your search orders on an existing one instead of
> passing whatever you want, that the behaviour you're seeing is
> non-standard. But it doesn't really matter, since you want to
> port to that system anyway...
No, this is for the start-up file for Niclos. gforth is my initial
development system, but it will be ported to a range of systems, and
the more that is done portably in the start-up file, the better.
I think its reasonable that a system might require a special wordlist
as the bottom of the search-order stack.
> >> Also I don't see why you would get yourself in that situation
> >> in the first place. Just define ONLY-FORTH or something, and
> >> use that instead of -1 SET-ORDER.
> > What if ONLY and FORTH are not present?
> As I said:
> : ONLY-FORTH -1 SET-ORDER GET-ORDER FORTH-WORDLIST SWAP 1+ SET-ORDER ;
There was my problem ... I sorted it out last night. I was doing all
search-order manipulations in the interpreter at that stage, since
Niclos tries to have a very small footprint in the Forth wordlist.
However, I have to have the Nicl-start operation in Forth ... and so I
reversed the factoring and did the above (plus adding the Nicl
wordlist).
> All those words are in CORE or SEARCH-ORDER, so if it's present
> and you haven't yet changed the default search order or
> compilation wordlist, then that should work just fine.
Of course I define Nicl-start into Forth, because it has to be outside
Nicl and the only words outside the Nicl namespace that are visible
inside Nicl are the words in FORTH-WORDLIST (and, if defined, Nicl-
support).
> > It is, of course, not an insuperable difficulty ... it's just one
> > more thing to add to the prefix file requirement, if there's no
> > standard portable way to do it.
> Sure, I'm just curious. I have this morbid fascination with the
> quirks people come up with when they implement Forth systems...
gforth has two wordlists in its search order when ONLY FORTH is
executed ROOT and FORTH-WORDLIST. I haven't re-read the documentation
to find out why (why is not an issue here, just whether) ... but it
throws an error on ``FORTH-WORDLIST 1 SET-ORDER''.
Not here:
Gforth 0.6.2, Copyright (C) 1995-2003 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
-1 set-order ok
order Root Root Forth ok
forth-wordlist 1 set-order ok
order Forth Forth ok
--
Neal Bridges
Quartus Forth http://www.quartus.net
Ah, so its just some kind of glitch ... I just now tried it several
times, several ways, and only got an error throw once.
So ...
: Nicl-start ( -- ) FORTH-WORDLIST 1 SET-ORDER
[DEFINED] Nicl-support [IF] Nicl-support Nicl+order [THEN]
Nicl Nicl+order
;
... it is, presuming the rest of the target set that implement the
SEARCH wordset respect that ... obviously for those that don't, what
the SEARCH wordset does is whatever the Nicl preface file for the
system makes it do.
I think, Bruce did
0 SET-ORDER
which indeed breaks gforth.
In *my* Forth, I check for search order sanity and if it's broken,
reset it with a warning.
0 SET-ORDER
ok[Dec]
WORDS
'WORDS' not found
WORDS<==!!!==>
^ -?
Return Stack: 04003bbc 04003b00 04009ec8
20:22:23 return stack saved (ch bytes), use the word .SAVED-RSTACK to
see it
stack empty ; 68826104 FORTH ( FORTH )
order & current: ; 68826104 FORTH ( FORTH )
reset to: 68826180 ROOT ( ROOT ) ; 68826104 FORTH
( FORTH )
WORDS
ROOT-WORDLIST FORTH-WORDLIST DEFINITIONS SET-CURRENT GET-ORDER SET-
ORDER PREVIOU
S ORDER ONLY ALSO ROOT FORTH WORDS ok[Dec]
That would be a bug. However, I cannot reproduce it.
- 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 2008: http://www.complang.tuwien.ac.at/anton/euroforth/ef08.html
Yes, that's a bug in 0.6.2. It is fixed in the development version.
Since I can't reproduce it reliably, its more likely that I am doing
something else wrong and that's when the error hits home. Just my bad
luck that the error when I brought that section of the scratch file
into the test file.