0 SET-ORDER why?

[Krishna Myneni]

Why is 0 a valid argument to SET-ORDER (from the optional Search-Order
word set)? It can leave a Forth system in a non-recoverable state.

---
16.6.1.2197

SET-ORDER ( widn . . . wid1 n – – )
Set the search order to the word lists identified by widn . . . wid1.
Subsequently, word list wid1 will be searched first, and word list widn
searched last.

If n is zero, empty the search order.

If n is minus one, set the search order to the implementation-defined
minimum search order. The minimum search order shall include the words
FORTH-WORDLIST and SET-ORDER.

A system shall allow n to be at least eight.
---

Sentences are separated for emphasis: "If n is zero, empty the search
order." Why?

In kForth (32/64), the sequence

0 SET-ORDER

leaves the Forth system in a non-recoverable state, and I have to use
Ctrl-C to break out back to the OS shell. This appears to be true in
Gforth as well, although Gforth traps Ctrl-C, so maybe one has to kill
the process from another shell.

See the examples below.

-- Krishna Myneni


=== kForth example ===
kForth-64 v 0.4.5 (Build: 2024-03-30)
Copyright (c) 1998--2023 Krishna Myneni
Contributions by: dpw gd mu bk abs tn cmb bg dnw imss
Provided under the GNU Affero General Public License, v3.0 or later


Ready!
order \ upon startup without command line args
[Forth] Root ok

\ set to the system's minimum search order (see 16.6.2.1965)
only
ok
order
Root ok \ minimum search order only contains the root wordlist

\ words in the root wordlist
words
5 words.
ORDER SET-ORDER FORTH-WORDLIST FORTH WORDS
ok

\ we can recover with the word FORTH (16.6.2.1590)
forth
ok
order
[Forth] Root ok \ back to startup state


only
ok
order
Root ok

\ What does 0 SET-ORDER do?
0 set-order
ok
order \ the word ORDER is no longer in the search order

ORDER
Line 10: VM Error(-13): Undefined word
order
forth \ the word FORTH is no longer in the search order

FORTH
Line 11: VM Error(-13): Undefined word
forth
bye

BYE \ we can't get back to OS shell without Ctrl-C
Line 12: VM Error(-13): Undefined word
bye
=== end of kForth example ===

=== Gforth example ===
Gforth 0.7.9_20220120
Authors: Anton Ertl, Bernd Paysan, Jens Wilke et al., for more type
`authors'
Copyright © 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<https://gnu.org/licenses/gpl.html>
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `help' for basic help
ok
order Forth Forth Root Forth ok \ on startup

only ok \ minimum search order ?
order Root Root Forth ok

\ words in the Root wordlist
words
order set-order forth-wordlist Forth words ok
forth ok
order Forth Root Forth ok \ recovered but different from startup

only ok
order Root Root Forth ok
0 set-order ok
order \ ORDER is no longer in the search order
*the terminal*:11:1: error: Undefined word

order<<<

Backtrace:
kernel/int.fs:321:10: 0 $7F0DAB00C3A0 throw

forth \ FORTH is no longer in the search order
*the terminal*:12:1: error: Undefined word

forth<<<

Backtrace:
kernel/int.fs:321:10: 0 $7F0DAB00C3A0 throw

bye \ BYE is no longer in the search order
*the terminal*:13:1: error: Undefined word

bye<<<

Backtrace:
kernel/int.fs:321:10: 0 $7F0DAB00C3A0 throw

\ Ctrl-C does not return to OS shell (trapped by Gforth)
*the terminal*:13:1: error: User interrupt |o:
Forth

bye<<<

Backtrace:
kernel/input.fs:216:30: 0 $7F0DAB019438 throw
kernel/input.fs:216:36: 1 $7F0DAB00E348 get-input-colored
except.fs:83:2: 2 $7F0DAB024DD8 execute [catch
frame]
kernel/int.fs:654:5: 3 $7F0DAB00DE38 catch
4 $7F0DB903FFC0
kernel/int.fs:658:5: 5 $7F0DAB00DEA0 bt-rp0-catch
=== end of Gforth example ===

[minforth]

IMO, it is a simple security mechanism against other users
breaking out of an application program and taking control
of the shell.

[a***@spenarnc.xs4all.nl]

Post by minforth
IMO, it is a simple security mechanism against other users
breaking out of an application program and taking control
of the shell.

I don't think so. The requirement to have FORTH-WORDLIST and SET-ORDER
means that you run the system normally after using this, including the
repl QUIT.
The intention of the standard that the minimum search order contains
a method to get the system under control. `FORTH' is way better than
manipulations with wordlists.
I cheated in ciforth. FORTH puts the FORTH-WORDLIST on top and is
a regular vocabulary/namespace.
In fact it is equivalent to
: FORTH GET-ORDER 1+ >R FORTH-WORDLIST R> SET-ORDER ;

So the ONLY namespace contains prefixes (handles numbers and strings)
and the word FORTH to recover.
FORTH and ONLY are named wordlist/ vocabularies.

To seal off in ciforth you can do:
'FORTH HIDDEN ONLY
From now on only numbers and strings are recognized.

Groetjes Albert

[Krishna Myneni]

Post by minforth
IMO, it is a simple security mechanism against other users
breaking out of an application program and taking control
of the shell.

That seems like a security concern for people who generate executables
and don't want users returning to the Forth shell, which would be useful
to commercial vendors who don't want users to have the full capability
of the Forth environment.

ISTM such a use does not warrant formal standardization in a language,
if that was the intent of specifically providing a way to disable the
Forth shell.


--
Krishna

[Anton Ertl]

Post by Krishna Myneni
Why is 0 a valid argument to SET-ORDER (from the optional Search-Order
word set)? It can leave a Forth system in a non-recoverable state.

So what? There are lots of ways to put a Forth system in a
non-recoverable state.

Post by Krishna Myneni
Sentences are separated for emphasis: "If n is zero, empty the search
order." Why?

Why not? It's what I would expect from 0 SET-ORDER anyway.

Is your question: "What potential uses does an empty search order
have?" ?

I have seen postings that suggest to use EVALUATE for converting
untrusted input into a number. There is of course no security
precautions in these postings, but at the very least one could empty
the search order before the EVALUATE and restore it after the EVALUATE
(with the EVALUATE being wrapped with CATCH). I thought about writing
out the source code, but the main things that would demonstrate is how
inconvenient GET-ORDER and SET-ORDER with their arbitrary number of
stack items are, and how inconvenient the arbitrary number of stack
items produced by EVALUATE is.

Of course, with recognizer sequences, the better way is to use a
recognizer sequence that only contains the number recognizers you
want, no need to mess with the search order.

Post by Krishna Myneni
In kForth (32/64), the sequence
0 SET-ORDER
leaves the Forth system in a non-recoverable state, and I have to use
Ctrl-C to break out back to the OS shell. This appears to be true in
Gforth as well, although Gforth traps Ctrl-C, so maybe one has to kill
the process from another shell.

In Gforth you can leave the text interpreter in the traditional Unix
way of doing Ctrl-D at the start of a line.

Restoring an empty search order to some more usable default by the
system CATCH handler would be a potential convenience feature, but I
have not experienced an empty search order as a problem yet, and I
don't remember users asking for such a feature, either. And it would
only catch

0 SET-ORDER

but not the functionally equivalent

WORDLIST 1 SET-ORDER

So why nerf one and not the other?

- anton

[dxf]

Post by Anton Ertl

Post by Krishna Myneni
Why is 0 a valid argument to SET-ORDER (from the optional Search-Order
word set)? It can leave a Forth system in a non-recoverable state.

So what? There are lots of ways to put a Forth system in a
non-recoverable state.

Post by Krishna Myneni
Sentences are separated for emphasis: "If n is zero, empty the search
order." Why?

Why not? It's what I would expect from 0 SET-ORDER anyway.
Is your question: "What potential uses does an empty search order
have?" ?
I have seen postings that suggest to use EVALUATE for converting
untrusted input into a number. There is of course no security
precautions in these postings, but at the very least one could empty
the search order before the EVALUATE and restore it after the EVALUATE
(with the EVALUATE being wrapped with CATCH). I thought about writing
out the source code, but the main things that would demonstrate is how
inconvenient GET-ORDER and SET-ORDER with their arbitrary number of
stack items are, and how inconvenient the arbitrary number of stack
items produced by EVALUATE is.
Of course, with recognizer sequences, the better way is to use a
recognizer sequence that only contains the number recognizers you
want, no need to mess with the search order.

Post by Krishna Myneni
In kForth (32/64), the sequence
0 SET-ORDER
leaves the Forth system in a non-recoverable state, and I have to use
Ctrl-C to break out back to the OS shell. This appears to be true in
Gforth as well, although Gforth traps Ctrl-C, so maybe one has to kill
the process from another shell.

In Gforth you can leave the text interpreter in the traditional Unix
way of doing Ctrl-D at the start of a line.
Restoring an empty search order to some more usable default by the
system CATCH handler would be a potential convenience feature, but I
have not experienced an empty search order as a problem yet, and I
don't remember users asking for such a feature, either. And it would
only catch
0 SET-ORDER
but not the functionally equivalent
WORDLIST 1 SET-ORDER
So why nerf one and not the other?

So after all that you don't have an explanation either? You implemented
it as instructed in the event someone finds a use.

"Yes, Zathras understand. ..... No, Zathras not understand, but Zathras do.
Zathras good at doings, not understandings."

[Ruvim]

Post by dxf

Post by Anton Ertl

Post by Krishna Myneni
Why is 0 a valid argument to SET-ORDER (from the optional Search-Order
word set)? It can leave a Forth system in a non-recoverable state.

So what? There are lots of ways to put a Forth system in a
non-recoverable state.

Post by Krishna Myneni
Sentences are separated for emphasis: "If n is zero, empty the search
order." Why?

Why not? It's what I would expect from 0 SET-ORDER anyway.
Is your question: "What potential uses does an empty search order
have?" ?
I have seen postings that suggest to use EVALUATE for converting
untrusted input into a number. There is of course no security
precautions in these postings, but at the very least one could empty
the search order before the EVALUATE and restore it after the EVALUATE
(with the EVALUATE being wrapped with CATCH). I thought about writing
out the source code, but the main things that would demonstrate is how
inconvenient GET-ORDER and SET-ORDER with their arbitrary number of
stack items are, and how inconvenient the arbitrary number of stack
items produced by EVALUATE is.
Of course, with recognizer sequences, the better way is to use a
recognizer sequence that only contains the number recognizers you
want, no need to mess with the search order.

Post by Krishna Myneni
In kForth (32/64), the sequence
0 SET-ORDER
leaves the Forth system in a non-recoverable state, and I have to use
Ctrl-C to break out back to the OS shell. This appears to be true in
Gforth as well, although Gforth traps Ctrl-C, so maybe one has to kill
the process from another shell.

In Gforth you can leave the text interpreter in the traditional Unix
way of doing Ctrl-D at the start of a line.
Restoring an empty search order to some more usable default by the
system CATCH handler would be a potential convenience feature, but I
have not experienced an empty search order as a problem yet, and I
don't remember users asking for such a feature, either. And it would
only catch
0 SET-ORDER
but not the functionally equivalent
WORDLIST 1 SET-ORDER
So why nerf one and not the other?

So after all that you don't have an explanation either? You implemented
it as instructed in the event someone finds a use.

I think, in this case it's better to specify behavior than to declare an
ambiguous condition.

Then the empty search order is the expected result by *induction*. It
would be strange to specify any other behavior in this case.



One possible use case:

: turnkey ( -- ) 0 set-order
also Target definitions
also Minimal also
;

It's found in
<https://github.com/eswartz/emul/blob/master/v9t9/v9t9-c/tools/Forth/site-forth/cross.fs>


Another possible use case:

: s-to-n ( addr u -- n )
depth >r
get-order n>r 0 set-order
['] evaluate ['] execute-interpreting catch
nr> set-order
depth 1- r> <> if -12 throw then
;

Where:

: compilation ( -- flag ) state @ 0<> ;
: enter-compilation ( -- ) ] ;
: leave-compilation ( -- ) postpone [ ;

: execute-interpreting ( i*x xt -- j*x )
compilation 0= if execute exit then
leave-compilation execute enter-compilation
;
: execute-compiling ( i*x xt -- j*x )
compilation if execute exit then
enter-compilation execute leave-compilation
;



BTW, I just realized that the words "execute-interpreting"
and "execute-compiling" are similar to well known word
"execute-parsing".



--
Ruvim

[dxf]

...
So after all that you don't have an explanation either?  You implemented
it as instructed in the event someone finds a use.

I think, in this case it's better to specify behavior than to declare an ambiguous condition.

No need to specify useless behaviours. u=0 in REPRESENT wasn't specified as
the TC couldn't imagine a use for it. Which was just as well as there was
a use for it the TC apparently overlooked.

Then the empty search order is the expected result by *induction*. It would be strange to specify any other behavior in this case.
  : turnkey ( -- ) 0 set-order
    also Target definitions
    also Minimal also
  ;
It's found in
<https://github.com/eswartz/emul/blob/master/v9t9/v9t9-c/tools/Forth/site-forth/cross.fs>
...

That seems useful.

[Gerry Jackson]

Post by dxf
No need to specify useless behaviours. u=0 in REPRESENT wasn't specified as
the TC couldn't imagine a use for it. Which was just as well as there was
a use for it the TC apparently overlooked.

What was this use of REPRESENT

[dxf]

Post by Gerry Jackson

No need to specify useless behaviours.  u=0 in REPRESENT wasn't specified as
the TC couldn't imagine a use for it.  Which was just as well as there was
a use for it the TC apparently overlooked.

What was this use of REPRESENT

Displaying single digit fractions to 0 decimal places e.g. 0.9 and 0.4

REPRESENT should handle this case but few do. An exception is:

VFX Forth 64 for Windows x64
© MicroProcessor Engineering Ltd, 1998-2023

0.9e pad 0 represent 2drop . pad 1 dump 1
0000:0000:01C2:EB00 31 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 1000000000000000
ok
0.4e pad 0 represent 2drop . pad 1 dump 1
0000:0000:01C2:EB00 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000
ok

Had ANS TC been aware of the need they would almost certainly have specified it.

[Ruvim]

Post by dxf

...
So after all that you don't have an explanation either?  You implemented
it as instructed in the event someone finds a use.

I think, in this case it's better to specify behavior than to declare an ambiguous condition.

No need to specify useless behaviours.

Even behavior that is useless in practice should be sometimes specified
to ensure *consistency* and expected effects.

BTW, do you think 0 PICK and 0 ROLL are useless?

Post by dxf
u=0 in REPRESENT wasn't specified as
the TC couldn't imagine a use for it.

<https://forth-standard.org/standard/float/REPRESENT>

Of course, it's specified. It's specified for any u, including 0.
For example:
"The character string shall consist of the u most significant digits"

If u is zero, the string must consist of zero digits.

Gforth throws exception -262, but is should not.
sp-forth/4 handles this case correctly.

Probably, "represent" may return false at the top if u is zero.

Post by dxf
Which was just as well as there was
a use for it the TC apparently overlooked.

What is the problem anyway that the behavior is specified for
"0 SET-ORDER"? What are bad consequences for systems or for users?


--
Ruvim

[dxf]

Post by dxf

...
So after all that you don't have an explanation either?  You implemented
it as instructed in the event someone finds a use.

I think, in this case it's better to specify behavior than to declare an ambiguous condition.

No need to specify useless behaviours.

Even behavior that is useless in practice should be sometimes specified to ensure *consistency* and expected effects.
BTW, do you think 0 PICK and 0 ROLL are useless?

No, because I've used them (at least in the case of PICK :)

Post by dxf
u=0 in REPRESENT wasn't specified as
the TC couldn't imagine a use for it.

<https://forth-standard.org/standard/float/REPRESENT>
Of course, it's specified. It's specified for any u, including 0.
  "The character string shall consist of the u most significant digits"
If u is zero, the string must consist of zero digits.

Spec says:

"u most significant digits of the significand"

Do you have a definition for '0 most significant digits of the significand' ?
I don't. Nor did ANS provide one.

Gforth throws exception  -262, but is should not.
sp-forth/4 handles this case correctly.
Probably, "represent" may return false at the top if u is zero.

No. The logical extrapolation of u approaching zero is that the number
is progressively rounded until it is either 0 or 1 according to which was
closest. Many implementations actually do this internally but screw up at
the interface because neither implementer nor ANS knew what u=0 should do.

...
What is the problem anyway that the behavior is specified for
"0 SET-ORDER"?  What are bad consequences for systems or for users?

It would be a problem if there were no use for it. It's not clear to me
that we're there yet.

[Ruvim]

Post by dxf

Post by dxf

...
So after all that you don't have an explanation either?  You implemented
it as instructed in the event someone finds a use.

I think, in this case it's better to specify behavior than to declare an ambiguous condition.

No need to specify useless behaviours.

Even behavior that is useless in practice should be sometimes specified to ensure *consistency* and expected effects.
BTW, do you think 0 PICK and 0 ROLL are useless?

No, because I've used them (at least in the case of PICK :)

Post by dxf
u=0 in REPRESENT wasn't specified as
the TC couldn't imagine a use for it.

<https://forth-standard.org/standard/float/REPRESENT>
Of course, it's specified. It's specified for any u, including 0.
  "The character string shall consist of the u most significant digits"
If u is zero, the string must consist of zero digits.

"u most significant digits of the significand"
Do you have a definition for '0 most significant digits of the significand' ?
I don't. Nor did ANS provide one.

It's seems obvious to me: 0 digits means the empty string.

Post by dxf

Gforth throws exception  -262, but is should not.
sp-forth/4 handles this case correctly.
Probably, "represent" may return false at the top if u is zero.

No. The logical extrapolation of u approaching zero is that the number
is progressively rounded until it is either 0 or 1 according to which was
closest.

"the significand represented as a decimal fraction", so each digit is
chosen from {0,1, ..., 9}.

Post by dxf
Many implementations actually do this internally but screw up at
the interface because neither implementer nor ANS knew what u=0 should do.

It's a problem of particular implementations.

The result is the empty string, and this is independent of how you
round. Then you don't have to round at all.


It reminds me of the choice between lazy evaluation and eager evaluation.

If the lazy evaluation approach, if the result does not depend on a
parameter in a certain case, then the parameter is not computed at all.

In the eager evaluation approach, computation of the result may never
halt because computation of an *unneeded* parameter is never halt in a
certain case.

Post by dxf

...
What is the problem anyway that the behavior is specified for
"0 SET-ORDER"?  What are bad consequences for systems or for users?

It would be a problem if there were no use for it. It's not clear to me
that we're there yet.

Well, this case can be found useful.


But, in general, what's wrong if a consistent and expected behavior is
specified for a case that is not used in real programs?


--
Ruvim

[dxf]

Post by Ruvim

Post by dxf

Post by dxf

...
So after all that you don't have an explanation either?  You implemented
it as instructed in the event someone finds a use.

I think, in this case it's better to specify behavior than to declare an ambiguous condition.

No need to specify useless behaviours.

Even behavior that is useless in practice should be sometimes specified to ensure *consistency* and expected effects.
BTW, do you think 0 PICK and 0 ROLL are useless?

No, because I've used them (at least in the case of PICK :)

Post by dxf
u=0 in REPRESENT wasn't specified as
the TC couldn't imagine a use for it.

<https://forth-standard.org/standard/float/REPRESENT>
Of course, it's specified. It's specified for any u, including 0.
   "The character string shall consist of the u most significant digits"
If u is zero, the string must consist of zero digits.

    "u most significant digits of the significand"
Do you have a definition for '0 most significant digits of the significand' ?
I don't.  Nor did ANS provide one.

It's seems obvious to me: 0 digits means the empty string.

REPRESENT does two things:
- Round the number to produce another number
- Convert the resulting number to a string

u=0 fails on the first step as there's no such thing as a number rounded to
zero significant digits. The resulting string is thus undefined.

Post by Ruvim

Post by dxf

Gforth throws exception -262, but is should not.
sp-forth/4 handles this case correctly.
Probably, "represent" may return false at the top if u is zero.

No. The logical extrapolation of u approaching zero is that the number
is progressively rounded until it is either 0 or 1 according to which was
closest.

"the significand represented as a decimal fraction", so each digit is chosen from {0,1, ..., 9}.

That refers to the resulting number after rounding. There's no difficulty
representing 1.0 as a fraction and adjusted exponent.

Post by Ruvim

Post by dxf
Many implementations actually do this internally but screw up at
the interface because neither implementer nor ANS knew what u=0 should do.

It's a problem of particular implementations.

It's a problem if they think ANS wanted them to return an empty string.

[dxf]

Post by dxf

Post by Ruvim

Post by dxf

Post by Ruvim
...
If u is zero, the string must consist of zero digits.

    "u most significant digits of the significand"
Do you have a definition for '0 most significant digits of the significand' ?
I don't.  Nor did ANS provide one.

It's seems obvious to me: 0 digits means the empty string.

- Round the number to produce another number
- Convert the resulting number to a string
u=0 fails on the first step as there's no such thing as a number rounded to
zero significant digits. The resulting string is thus undefined.

Since posting the above I discovered the issue had been put to 200x with the
following response:

"So with u=0 zero characters must be written to c-addr. Any implementation
that writes something there is buggy. An exception for u=0 is also a bug
(and in case of Gforth this bug will be fixed).

There is no basis for any claim that the u=0 case is unclear or unspecified.
And unsurprisingly, the person who claimed so presented no argument that
would support such a claim."

Presumably that was a reference to me. I consider the rationale I gave above
to be quite solid - unbreakable in fact.

It's good to know VFX' REPRESENT is "buggy" according to 200x. I'll be keen
to see whether they fix it.

[dxf]

...
Gforth throws exception  -262, but is should not.
sp-forth/4 handles this case correctly.

Attempting to do u=0 on Windows Gforth (2020) results in the entire app
crashing. AFAIK its REPRESENT is based on ecvt() so anything is possible
when fed with an illegal parameter.

I believe SP-Forth uses one of my REPRESENT implementations from ~2004.
It doesn't surprise me you got that result :) For those interested a superior
implementation can be found below. Included is a forth floating point output
package so good I've not needed REPRESENT since.

Represent35.txt

https://drive.google.com/drive/folders/1kh2WcPUc3hQpLcz7TQ-YQiowrozvxfGw

[Gerry Jackson]

  : turnkey ( -- ) 0 set-order
    also Target definitions
    also Minimal also
  ;

ALSO duplicates the wordlist at the head of the search order. If the
search order is empty there is nothing to duplicate. Therefore ALSO
applied to an empty search order ought to be an ambiguous condition.

Presumably the above definition works because a target wordlist replaces
whatever garbage ALSO leaves in the search order. So the definition
might as well have 0 1 SET-ORDER instead of 0 SET-ORDER ALSO.
Or better still TARGET-WORDLIST 1 SET-ORDER. Either removes the above
justification for 0 SET-ORDER.

But having said that it is better for 0 SET-ORDER to do what is natural
instead of yet another ambiguous condition.

: s-to-n ( addr u -- n )
depth >r
get-order n>r 0 set-order
['] evaluate ['] execute-interpreting catch
nr> set-order
depth 1- r> <> if -12 throw then
;

This is a better use case e.g. if BASE is greater than decimal 10
converting an alphanumeric string to a number could clash with a word in
the dictionary. Having an empty search order eliminates that possibility.

Incidentally another possibility is that if ['] EVALUATE is replaced in
the above definition with ['] SOME-RECOGNISER, that could be the basis
for an ANS/FORTH 2012 compatible way of implementing recognisers. If the
recogniser fails restore the search order and try again.

[a***@spenarnc.xs4all.nl]

Post by Gerry Jackson

  : turnkey ( -- ) 0 set-order
    also Target definitions
    also Minimal also
  ;

ALSO duplicates the wordlist at the head of the search order. If the
search order is empty there is nothing to duplicate. Therefore ALSO
applied to an empty search order ought to be an ambiguous condition.
Presumably the above definition works because a target wordlist replaces
whatever garbage ALSO leaves in the search order. So the definition
might as well have 0 1 SET-ORDER instead of 0 SET-ORDER ALSO.
Or better still TARGET-WORDLIST 1 SET-ORDER. Either removes the above
justification for 0 SET-ORDER.
But having said that it is better for 0 SET-ORDER to do what is natural
instead of yet another ambiguous condition.

: s-to-n ( addr u -- n )
depth >r
get-order n>r 0 set-order
['] evaluate ['] execute-interpreting catch
nr> set-order
depth 1- r> <> if -12 throw then
;

This is a better use case e.g. if BASE is greater than decimal 10
converting an alphanumeric string to a number could clash with a word in
the dictionary. Having an empty search order eliminates that possibility.
Incidentally another possibility is that if ['] EVALUATE is replaced in
the above definition with ['] SOME-RECOGNISER, that could be the basis
for an ANS/FORTH 2012 compatible way of implementing recognisers. If the
recogniser fails restore the search order and try again.

I'm more and more convinced that the ciforth solution to make ONLY
a wordlist and stick all the number stuff (plus strings, say denotations) there
is ideal.
Add the rule that you simply cannot the remove the minimal search order,
which may perfect sense.
The only non-ISO aspect is that FORTH-WORDLIST and SET-ORDER is missing.
This is just as well, implementing SET-ORDER politically correctly
would bloat the ciforth kernel with 20%, at least that is my impression
from the discussion here.

And besides shuffling the wordlists searched for is a terrible idea.
I have not seen a use case for that.
Think of python. If you import all with *, at least the underlying
assumption is that the libraries contain no conflicting names
such that the order doesn't matter. Imagine that you can somehow
"unimport integral *" .
The idea from ENVRIONMENT that was supposed to find out portably what
facilities are to be loaded. No sensible use case.

A sensible use of wordlist is e.g.
ALSO INLINING
INCLUDE modulo.frt
PREVIOUS
This adds INLINING to the search order to have all the operators of
modulo calculations automatically inlined: +m -m *m ^m .
Then back off.
Or adding the ASSEMBLER namespace temporarily to add code words.

Or a word like IMPORT that makes an alias from a named wordlist
into the current wordlist (assuming current=context).

Post by Gerry Jackson
--
Gerry

Groetjes Albert

[minforth]

One should not forget that the linear search-order concept has
a long history (CONTEXT et al) and has served mostly well for
many small Forth applications. So be gracious towards some
ambiguities.

More modern languages with a wider application spectrum need
more elaborated namespace management. Should anyone invest brain
and time into a novel Forth namespace management concept, search
trees (instead of today's global search-order list) would be a
good place to start with.

This would facilitate early binding, modules, public/private
library handling etc. Of course these things are not new and
already there, but without common basis - and so everyone is
cooking their own soup.

[dxf]

   : turnkey ( -- ) 0 set-order
     also Target definitions
     also Minimal also
   ;

ALSO duplicates the wordlist at the head of the search order. If the search order is empty there is nothing to duplicate. Therefore ALSO applied to an empty search order ought to be an ambiguous condition.
Presumably the above definition works because a target wordlist replaces whatever garbage ALSO leaves in the search order. So the definition might as well have 0 1 SET-ORDER instead of 0 SET-ORDER ALSO.
Or better still TARGET-WORDLIST 1 SET-ORDER. Either removes the above justification for 0 SET-ORDER.

( orig from ANS)
: ALSO ( -- ) GET-ORDER OVER SWAP 1+ SET-ORDER ;

( smarter)
: ALSO ( -- )
GET-ORDER DUP IF OVER ELSE FORTH-WORDLIST THEN
SWAP 1+ SET-ORDER ;

[Krishna Myneni]

Post by Gerry Jackson

   : turnkey ( -- ) 0 set-order
     also Target definitions
     also Minimal also
   ;

ALSO duplicates the wordlist at the head of the search order. If the
search order is empty there is nothing to duplicate. Therefore ALSO
applied to an empty search order ought to be an ambiguous condition.
Presumably the above definition works because a target wordlist replaces
whatever garbage ALSO leaves in the search order. So the definition
might as well have 0 1 SET-ORDER instead of 0 SET-ORDER ALSO.
Or better still TARGET-WORDLIST 1 SET-ORDER. Either removes the above
justification for 0 SET-ORDER.

Good analysis showing that

1) The definition of TURNKEY is flawed.

2) 0 SET-ORDER is not necessary.

Post by Gerry Jackson
But having said that it is better for 0 SET-ORDER to do what is natural
instead of yet another ambiguous condition.

    : s-to-n ( addr u -- n )
      depth >r
      get-order n>r 0 set-order
        ['] evaluate ['] execute-interpreting catch
      nr> set-order
      depth 1- r> <> if -12 throw then
    ;

This is a better use case e.g. if BASE is greater than decimal 10
converting an alphanumeric string to a number could clash with a word in
the dictionary. Having an empty search order eliminates that possibility.

This use case is convoluted and there may be a better of dealing with
the anticipated problem. If not, we should consider what's missing in
Forth allowing us to solve the problem more directly.


No one has pointed to a need for 0 SET-ORDER in interpretation state,
and there is no to undo its use in interpretation state in a standard.
Furthermore an empty search order contradicts the concept of a minimum
search order.

The solutions are:

1) leave everything as is, and live with the contradiction and the
hazard of performing 0 SET-ORDER in interpretation state.

2) make SET-ORDER state-smart, and live with the contradiction. This
will potentially break code.

3) disallow zero as an argument to SET-ORDER e.g. throw an error for zero.

Am I missing any other options?

Personally, I favor 3) -- throwing an error when zero is an argument to
SET-ORDER.

--
Krishna

Personally


2)

[Krishna Myneni]

Post by Krishna Myneni

Post by Gerry Jackson

   : turnkey ( -- ) 0 set-order
     also Target definitions
     also Minimal also
   ;

ALSO duplicates the wordlist at the head of the search order. If the
search order is empty there is nothing to duplicate. Therefore ALSO
applied to an empty search order ought to be an ambiguous condition.
Presumably the above definition works because a target wordlist
replaces whatever garbage ALSO leaves in the search order. So the
definition might as well have 0 1 SET-ORDER instead of 0 SET-ORDER ALSO.
Or better still TARGET-WORDLIST 1 SET-ORDER. Either removes the above
justification for 0 SET-ORDER.

Good analysis showing that
1) The definition of TURNKEY is flawed.
2) 0 SET-ORDER is not necessary.

Post by Gerry Jackson
But having said that it is better for 0 SET-ORDER to do what is
natural instead of yet another ambiguous condition.
 >
 >    : s-to-n ( addr u -- n )
 >      depth >r
 >      get-order n>r 0 set-order
 >        ['] evaluate ['] execute-interpreting catch
 >      nr> set-order
 >      depth 1- r> <> if -12 throw then
 >    ;
This is a better use case e.g. if BASE is greater than decimal 10
converting an alphanumeric string to a number could clash with a word
in the dictionary. Having an empty search order eliminates that
possibility.

This use case is convoluted and there may be a better of dealing with
the anticipated problem. If not, we should consider what's missing in
Forth allowing us to solve the problem more directly.
No one has pointed to a need for 0 SET-ORDER in interpretation state,
and there is no to undo its use in interpretation state in a standard.
Furthermore an empty search order contradicts the concept of a minimum
search order.
1) leave everything as is, and live with the contradiction and the
hazard of performing 0 SET-ORDER in interpretation state.
2) make SET-ORDER state-smart, and live with the contradiction. This
will potentially break code.
3) disallow zero as an argument to SET-ORDER e.g. throw an error for zero.
Am I missing any other options?
Personally, I favor 3) -- throwing an error when zero is an argument to
SET-ORDER.

Edits:

No one has pointed to a need for 0 SET-ORDER in interpretation state,
and there is no standard way to undo its use in interpretation state.

3) disallow zero as an argument to SET-ORDER e.g. throw an error for
zero. This will break existing code where zero is an argument to SET-ORDER.

Any idea of frequency of usage for 0 SET-ORDER . I don't believe I have
ever used it in a definition.

--
KM

[Gerry Jackson]

Post by Krishna Myneni

Post by Krishna Myneni

Post by Gerry Jackson

   : turnkey ( -- ) 0 set-order
     also Target definitions
     also Minimal also
   ;

ALSO duplicates the wordlist at the head of the search order. If the
search order is empty there is nothing to duplicate. Therefore ALSO
applied to an empty search order ought to be an ambiguous condition.
Presumably the above definition works because a target wordlist
replaces whatever garbage ALSO leaves in the search order. So the
definition might as well have 0 1 SET-ORDER instead of 0 SET-ORDER ALSO.
Or better still TARGET-WORDLIST 1 SET-ORDER. Either removes the above
justification for 0 SET-ORDER.

Good analysis showing that
1) The definition of TURNKEY is flawed.
2) 0 SET-ORDER is not necessary.

Post by Gerry Jackson
But having said that it is better for 0 SET-ORDER to do what is
natural instead of yet another ambiguous condition.
 >
 >    : s-to-n ( addr u -- n )
 >      depth >r
 >      get-order n>r 0 set-order
 >        ['] evaluate ['] execute-interpreting catch
 >      nr> set-order
 >      depth 1- r> <> if -12 throw then
 >    ;
This is a better use case e.g. if BASE is greater than decimal 10
converting an alphanumeric string to a number could clash with a word
in the dictionary. Having an empty search order eliminates that
possibility.

This use case is convoluted and there may be a better of dealing with
the anticipated problem.

It has been a real problem, years ago I compiled some preset data in Hex
(before the $ prefix was standardised). Something like A5 c, 13 c, D0 c, ...
and the application worked on a number of systems and then crashed on
another standard system. On investigation I found that D0 was a defined
word in that system - hence a crash. OK the $ prefix solves that but not
the general problem e.g. BASE = #24 say

Post by Krishna Myneni

Post by Krishna Myneni
If not, we should consider what's missing in
Forth allowing us to solve the problem more directly.
No one has pointed to a need for 0 SET-ORDER in interpretation state,
and there is no to undo its use in interpretation state in a standard.
Furthermore an empty search order contradicts the concept of a minimum
search order.
1) leave everything as is, and live with the contradiction and the
hazard of performing 0 SET-ORDER in interpretation state.

I favour this, there are other ways of achieving the effect of
0 SET-ORDER in interpretation mode, for example

1) WORDLIST 1 SET-ORDER

2) Using PREVIOUS on a search order of FORTH-WORDLIST only (assuming
FORTH-WORDLIST contains PREVIOUS)

3) ...

I suspect trying to ban every possibility isn't worth it

Post by Krishna Myneni

Post by Krishna Myneni
2) make SET-ORDER state-smart, and live with the contradiction. This
will potentially break code.
3) disallow zero as an argument to SET-ORDER e.g. throw an error for zero.
Am I missing any other options?
Personally, I favor 3) -- throwing an error when zero is an argument
to SET-ORDER.

No one has pointed to a need for 0 SET-ORDER in interpretation state,
and there is no standard way to undo its use in interpretation state.
3) disallow zero as an argument to SET-ORDER e.g. throw an error for
zero. This will break existing code where zero is an argument to SET-ORDER.
Any idea of frequency of usage for 0 SET-ORDER . I don't believe I have
ever used it in a definition.
--
KM

[Krishna Myneni]

...

Post by Krishna Myneni
1) leave everything as is, and live with the contradiction and the
hazard of performing 0 SET-ORDER in interpretation state.

I favour  this, there are other ways of achieving the effect of
0 SET-ORDER in interpretation mode, for example
1) WORDLIST 1 SET-ORDER
2)  Using PREVIOUS on a search order of FORTH-WORDLIST only (assuming
FORTH-WORDLIST contains PREVIOUS)
3) ...
I suspect trying to ban every possibility isn't worth it

Since SET-ORDER is a standardized word and changing its behavior would
break existing code, it's not the right approach anyway. The options
2--3 are really for suggesting another word which has the behavior of
SET-ORDER except for the zero arg case.

--
Krishna

[dxf]

Post by Krishna Myneni

Post by Krishna Myneni

   : turnkey ( -- ) 0 set-order
     also Target definitions
     also Minimal also
   ;

ALSO duplicates the wordlist at the head of the search order. If the search order is empty there is nothing to duplicate. Therefore ALSO applied to an empty search order ought to be an ambiguous condition.
Presumably the above definition works because a target wordlist replaces whatever garbage ALSO leaves in the search order. So the definition might as well have 0 1 SET-ORDER instead of 0 SET-ORDER ALSO.
Or better still TARGET-WORDLIST 1 SET-ORDER. Either removes the above justification for 0 SET-ORDER.

Good analysis showing that
1) The definition of TURNKEY is flawed.
2) 0 SET-ORDER is not necessary.

But having said that it is better for 0 SET-ORDER to do what is natural instead of yet another ambiguous condition.
 >
 >    : s-to-n ( addr u -- n )
 >      depth >r
 >      get-order n>r 0 set-order
 >        ['] evaluate ['] execute-interpreting catch
 >      nr> set-order
 >      depth 1- r> <> if -12 throw then
 >    ;
This is a better use case e.g. if BASE is greater than decimal 10 converting an alphanumeric string to a number could clash with a word in the dictionary. Having an empty search order eliminates that possibility.

This use case is convoluted and there may be a better of dealing with the anticipated problem. If not, we should consider what's missing in Forth allowing us to solve the problem more directly.
No one has pointed to a need for 0 SET-ORDER in interpretation state, and there is no to undo its use in interpretation state in a standard. Furthermore an empty search order contradicts the concept of a minimum search order.
1) leave everything as is, and live with the contradiction and the hazard of performing 0 SET-ORDER in interpretation state.
2) make SET-ORDER state-smart, and live with the contradiction. This will potentially break code.
3) disallow zero as an argument to SET-ORDER e.g. throw an error for zero.
Am I missing any other options?
Personally, I favor 3) -- throwing an error when zero is an argument to SET-ORDER.

No one has pointed to a need for 0 SET-ORDER in interpretation state,
and there is no standard way to undo its use in interpretation state.
3) disallow zero as an argument to SET-ORDER e.g. throw an error for zero. This will break existing code where zero is an argument to SET-ORDER.
Any idea of frequency of usage for 0 SET-ORDER . I don't believe I have ever used it in a definition.

It appears this topic has come up before:

https://groups.google.com/g/comp.lang.forth/c/Kku0wXJ8zMs/m/CgWkZ7Kl_EMJ

Other posts I've seen suggest Mitch Bradley may have been behind GET-ORDER SET-ORDER
(originally a fix for ONLY/ALSO). May be worth contacting him.

[a***@spenarnc.xs4all.nl]

Post by Krishna Myneni

Post by Gerry Jackson

   : turnkey ( -- ) 0 set-order
     also Target definitions
     also Minimal also
   ;

ALSO duplicates the wordlist at the head of the search order. If the
search order is empty there is nothing to duplicate. Therefore ALSO
applied to an empty search order ought to be an ambiguous condition.
Presumably the above definition works because a target wordlist replaces
whatever garbage ALSO leaves in the search order. So the definition
might as well have 0 1 SET-ORDER instead of 0 SET-ORDER ALSO.
Or better still TARGET-WORDLIST 1 SET-ORDER. Either removes the above
justification for 0 SET-ORDER.

Good analysis showing that
1) The definition of TURNKEY is flawed.
2) 0 SET-ORDER is not necessary.

Post by Gerry Jackson
But having said that it is better for 0 SET-ORDER to do what is natural
instead of yet another ambiguous condition.

    : s-to-n ( addr u -- n )
      depth >r
      get-order n>r 0 set-order
        ['] evaluate ['] execute-interpreting catch
      nr> set-order
      depth 1- r> <> if -12 throw then
    ;

This is a better use case e.g. if BASE is greater than decimal 10
converting an alphanumeric string to a number could clash with a word in
the dictionary. Having an empty search order eliminates that possibility.

This use case is convoluted and there may be a better of dealing with
the anticipated problem. If not, we should consider what's missing in
Forth allowing us to solve the problem more directly.
No one has pointed to a need for 0 SET-ORDER in interpretation state,
and there is no to undo its use in interpretation state in a standard.
Furthermore an empty search order contradicts the concept of a minimum
search order.
1) leave everything as is, and live with the contradiction and the
hazard of performing 0 SET-ORDER in interpretation state.
2) make SET-ORDER state-smart, and live with the contradiction. This
will potentially break code.
3) disallow zero as an argument to SET-ORDER e.g. throw an error for zero.
Am I missing any other options?

4) Use wordlists as a pure stack. Also ASSEMBLER .. PREVIOUS.
Define the minumum search order as only handling numbers and other constants.
Declare SET-ORDER and GET-ORDER obsolete.

Post by Krishna Myneni
Personally, I favor 3) -- throwing an error when zero is an argument to
SET-ORDER.
--
Krishna
Personally
2)

[Krishna Myneni]

...

Post by a***@spenarnc.xs4all.nl

Post by Krishna Myneni
1) leave everything as is, and live with the contradiction and the
hazard of performing 0 SET-ORDER in interpretation state.
2) make SET-ORDER state-smart, and live with the contradiction. This
will potentially break code.
3) disallow zero as an argument to SET-ORDER e.g. throw an error for zero.
Am I missing any other options?

4) Use wordlists as a pure stack. Also ASSEMBLER .. PREVIOUS.
Define the minumum search order as only handling numbers and other constants.
Declare SET-ORDER and GET-ORDER obsolete.

The whole Search Order word set is clunky and has a cobbled together
feel about it. It is also difficult to integrate a named modules system
into which provides Public/Private definitions into the standard words
e.g. making ORDER list the names of the modules isn't easy.

A stack model for the search order may be the way to go. It would be
more intuitive to Forth users than having to remember ONLY ALSO PREVIOUS
etc.

Currently the standard defines what a minimum search order should
contain but then promptly disregards it by standardizing 0 SET-ORDER.
This is dangerous in interpretation mode, and, while it may have uses in
compilation mode, within a definition where the prior search order can
be restored (or not), the notion of a well-defined minimum search order
should be a strong guarantee to the Forth programmer and not allowed to
be violated easily.

--
Krishna

[a***@spenarnc.xs4all.nl]

Post by Krishna Myneni
...
The whole Search Order word set is clunky and has a cobbled together
feel about it. It is also difficult to integrate a named modules system
into which provides Public/Private definitions into the standard words
e.g. making ORDER list the names of the modules isn't easy.
A stack model for the search order may be the way to go. It would be
more intuitive to Forth users than having to remember ONLY ALSO PREVIOUS
etc.
Currently the standard defines what a minimum search order should
contain but then promptly disregards it by standardizing 0 SET-ORDER.
This is dangerous in interpretation mode, and, while it may have uses in
compilation mode, within a definition where the prior search order can
be restored (or not), the notion of a well-defined minimum search order
should be a strong guarantee to the Forth programmer and not allowed to
be violated easily.

I have taken the liberty to replace VOCABULARY with NAMESPACE in ciforth.
NAMESPACE is a named wordlist that pushes itself to the search order.
If you formulate it an archaic way, "ALSO is put in the body of the
CREATE DOES> word NAMESPACE."
In fact in this approach, `ALSO is all but superfluous.
It is from the time, one had merely two slots for wordlists.
Wordlist's , namespaces that have itself no name, are so akward.

Post by Krishna Myneni
--
Krishna

Groetjes Albert

[Ruvim]

Post by Gerry Jackson

   : turnkey ( -- ) 0 set-order
     also Target definitions
     also Minimal also
   ;

ALSO duplicates the wordlist at the head of the search order. If the
search order is empty there is nothing to duplicate. Therefore ALSO
applied to an empty search order ought to be an ambiguous condition.

Agree. This code is formally incorrect.

An ambiguous condition should be declared for ALSO
when the search order is empty.

I collect such cases at
<https://github.com/ForthHub/standard-evolution/issues/5>

Then a proposal should be prepared.

Post by Gerry Jackson
Presumably the above definition works because a target wordlist replaces
whatever garbage ALSO leaves in the search order. So the definition
might as well have 0 1 SET-ORDER instead of 0 SET-ORDER ALSO.
Or better still TARGET-WORDLIST 1 SET-ORDER. Either removes the above
justification for 0 SET-ORDER.

As I later discovered, this "turnkey" is from Gforth, and it was corrected:
<https://github.com/forthy42/gforth/blob/ba915873/cross.fs#L4570>

Post by Gerry Jackson
But having said that it is better for 0 SET-ORDER to do what is natural
instead of yet another ambiguous condition.

    : s-to-n ( addr u -- n )
      depth >r
      get-order n>r 0 set-order
        ['] evaluate ['] execute-interpreting catch
      nr> set-order
      depth 1- r> <> if -12 throw then
    ;

There is a mistake (due to additions in my old example)

A corrected variant:

: s-to-n ( addr u -- x )
depth >r
get-order n>r 0 set-order
['] evaluate ['] execute-interpreting catch
nr> set-order throw
depth 1+ r> <> if -12 throw then
;

Post by Gerry Jackson
This is a better use case e.g. if BASE is greater than decimal 10
converting an alphanumeric string to a number could clash with a word in
the dictionary. Having an empty search order eliminates that possibility.
Incidentally another possibility is that if ['] EVALUATE is replaced in
the above definition with ['] SOME-RECOGNISER, that could be the basis
for an ANS/FORTH 2012 compatible way of implementing recognisers. If the
recogniser fails restore the search order and try again.

My position is that no recognizer can have side effects (other then
items on the data stack and/or floating-point stack).

Although, this approach can be used to *implement* SOME-RECOGNISER.


--
Ruvim

[a***@spenarnc.xs4all.nl]

Post by Ruvim

Post by Gerry Jackson

   : turnkey ( -- ) 0 set-order
     also Target definitions
     also Minimal also
   ;

ALSO duplicates the wordlist at the head of the search order. If the
search order is empty there is nothing to duplicate. Therefore ALSO
applied to an empty search order ought to be an ambiguous condition.

Agree. This code is formally incorrect.
An ambiguous condition should be declared for ALSO
when the search order is empty.
I collect such cases at
<https://github.com/ForthHub/standard-evolution/issues/5>
Then a proposal should be prepared.

Post by Gerry Jackson
Presumably the above definition works because a target wordlist replaces
whatever garbage ALSO leaves in the search order. So the definition
might as well have 0 1 SET-ORDER instead of 0 SET-ORDER ALSO.
Or better still TARGET-WORDLIST 1 SET-ORDER. Either removes the above
justification for 0 SET-ORDER.

<https://github.com/forthy42/gforth/blob/ba915873/cross.fs#L4570>

Post by Gerry Jackson
But having said that it is better for 0 SET-ORDER to do what is natural
instead of yet another ambiguous condition.

    : s-to-n ( addr u -- n )
      depth >r
      get-order n>r 0 set-order
        ['] evaluate ['] execute-interpreting catch
      nr> set-order
      depth 1- r> <> if -12 throw then
    ;

There is a mistake (due to additions in my old example)
: s-to-n ( addr u -- x )
depth >r
get-order n>r 0 set-order
['] evaluate ['] execute-interpreting catch
nr> set-order throw
depth 1+ r> <> if -12 throw then
;

Post by Gerry Jackson
This is a better use case e.g. if BASE is greater than decimal 10
converting an alphanumeric string to a number could clash with a word in
the dictionary. Having an empty search order eliminates that possibility.
Incidentally another possibility is that if ['] EVALUATE is replaced in
the above definition with ['] SOME-RECOGNISER, that could be the basis
for an ANS/FORTH 2012 compatible way of implementing recognisers. If the
recogniser fails restore the search order and try again.

My position is that no recognizer can have side effects (other then
items on the data stack and/or floating-point stack).

I second that. Moreover the items would have to be the same in
interpret and compilation mode.
At least as a starting point, otherwise Forth degenerates to a
tangled web of special purpose interpreters.

Post by Ruvim
Although, this approach can be used to *implement* SOME-RECOGNISER.
--
Ruvim

[Ruvim]

[...]

Post by a***@spenarnc.xs4all.nl

Post by Ruvim
: s-to-n ( addr u -- x )
depth >r
get-order n>r 0 set-order
['] evaluate ['] execute-interpreting catch
nr> set-order throw
depth 1+ r> <> if -12 throw then
;

Post by Gerry Jackson
This is a better use case e.g. if BASE is greater than decimal 10
converting an alphanumeric string to a number could clash with a word in
the dictionary. Having an empty search order eliminates that possibility.
Incidentally another possibility is that if ['] EVALUATE is replaced in
the above definition with ['] SOME-RECOGNISER, that could be the basis
for an ANS/FORTH 2012 compatible way of implementing recognisers. If the
recogniser fails restore the search order and try again.

My position is that no recognizer can have side effects (other then
items on the data stack and/or floating-point stack).

I second that.

My rationale:
"Recognizer protocol", 2020-07-04
<news:rdpu54$pfn$***@dont-email.me>

<https://groups.google.com/g/comp.lang.forth/c/yuNZEvq8EqA/m/-FcvRcwRAQAJ>

Post by a***@spenarnc.xs4all.nl
Moreover the items would have to be the same in
interpret and compilation mode.

Agreed.


Rationale:

1. In most use cases the result of recognizing does not depend on STATE
(and when it depends, like in cmForth, it can be made independent).

2. One useful thing about recognizers is that they can be used for more
than just the purpose of lexeme translation. If we would need to only
translate lexemes (i.e., to compile or interpret a lexeme depending on
STATE) — no need to separate the step of recognizing.

3. If we recognize a lexeme not for further immediate translation, and
the result may depend on STATE, we will need to change STATE before
recognizing (or use some helpers to indicate our intention). This only
complicates some use cases and does not simplify anything.

Post by a***@spenarnc.xs4all.nl
At least as a starting point, otherwise Forth degenerates to a
tangled web of special purpose interpreters.

--
Ruvim

[Gerry Jackson]

Post by Ruvim

Post by Gerry Jackson

   : turnkey ( -- ) 0 set-order
     also Target definitions
     also Minimal also
   ;

ALSO duplicates the wordlist at the head of the search order. If the
search order is empty there is nothing to duplicate. Therefore ALSO
applied to an empty search order ought to be an ambiguous condition.

Agree. This code is formally incorrect.
An ambiguous condition should be declared for ALSO
when the search order is empty.
I collect such cases at
<https://github.com/ForthHub/standard-evolution/issues/5>
Then a proposal should be prepared.

Another ambiguous condition that should be added is the execution of
DEFINITIONS when the search order is empty

[a***@spenarnc.xs4all.nl]

Post by Anton Ertl

Post by Krishna Myneni
Why is 0 a valid argument to SET-ORDER (from the optional Search-Order
word set)? It can leave a Forth system in a non-recoverable state.

So what? There are lots of ways to put a Forth system in a
non-recoverable state.

Post by Krishna Myneni
Sentences are separated for emphasis: "If n is zero, empty the search
order." Why?

Why not? It's what I would expect from 0 SET-ORDER anyway.

0 SET-ORDER puts the minimum search order in place.
Then there are FORTH-WORDLIST and SET-ORDER present to get
the system under control. Am I mistaken?

<SNIP>

Post by Anton Ertl
- anton

Groetjes Albert

[minforth]

You described -1 SET-ORDER , whereas 0 SET-ORDER empties.

[Krishna Myneni]

Post by a***@spenarnc.xs4all.nl

Post by Anton Ertl

Post by Krishna Myneni
Why is 0 a valid argument to SET-ORDER (from the optional Search-Order
word set)? It can leave a Forth system in a non-recoverable state.

So what? There are lots of ways to put a Forth system in a
non-recoverable state.

Post by Krishna Myneni
Sentences are separated for emphasis: "If n is zero, empty the search
order." Why?

Why not? It's what I would expect from 0 SET-ORDER anyway.

0 SET-ORDER puts the minimum search order in place.
Then there are FORTH-WORDLIST and SET-ORDER present to get
the system under control. Am I mistaken?

According to Anton's interpretation you are mistaken.

0 SET-ORDER empties the search order, which is commonly taken to be
understood as nothing exists in the search order. Of course this
contradicts the notion in the standard of a "minimum search order which
contains the words FORTH-WORDLIST and SET-ORDER".

--
Krishna

[Krishna Myneni]

Post by Anton Ertl

Post by Krishna Myneni
Why is 0 a valid argument to SET-ORDER (from the optional Search-Order
word set)? It can leave a Forth system in a non-recoverable state.

So what? There are lots of ways to put a Forth system in a
non-recoverable state.
...

By design? No.

--
Krishna

[Anton Ertl]

Post by Krishna Myneni

Post by Anton Ertl

Post by Krishna Myneni
Why is 0 a valid argument to SET-ORDER (from the optional Search-Order
word set)? It can leave a Forth system in a non-recoverable state.

So what? There are lots of ways to put a Forth system in a
non-recoverable state.
...

By design? No.

Does it matter?

If the user accidentially puts the Forth system in a non-recoverable
state, there is no difference between "by design" (e.g., 0 SET-ORDER)
and "by doing non-standard things".

If the user intentionally puts the Forth system in a non-recoverable
state (e.g.,
<https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Crash-Course-Tutorial.html>),
it does not matter, either.

- anton

[Hans Bezemer]

Post by Anton Ertl

Post by Krishna Myneni

Post by Anton Ertl

Post by Krishna Myneni
Why is 0 a valid argument to SET-ORDER (from the optional Search-Order
word set)? It can leave a Forth system in a non-recoverable state.

So what? There are lots of ways to put a Forth system in a
non-recoverable state.
...

By design? No.

Does it matter?
If the user accidentially puts the Forth system in a non-recoverable
state, there is no difference between "by design" (e.g., 0 SET-ORDER)
and "by doing non-standard things".
If the user intentionally puts the Forth system in a non-recoverable
state (e.g.,
<https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Crash-Course-Tutorial.html>),
it does not matter, either.
- anton

Interesting challenge! 4tH supports all these words, so I should at
least be able to compile it. But no:

4tH message: Undefined name at word 5

It cannot compile, because CATCH isn't *defined* - it's a builtin. It
has no address to point to. So I change it slightly:

: (catch) catch ;
: (quit) quit ;

0 0 !
here execute
' (catch) >body 20 erase abort
' (quit) >body 20 erase

And yes, it compiles cleanly. However, when executing:

Executing; Word 9: Bad variable

Because you're not allowed to anything write at that address. You can
read it though. Let's remove it..

Executing; Word 8: Stack empty

Yeah, EXECUTE requires an execution token. The stack is empty.
If we skip that one too, it runs! That is because "10" and "14" are
addresses in the 256 byte TIB, which is located in the Character
Segment. That's where ERASE does its job.

So that's harmless..

That was fun!

Hans Bezemer

[Krishna Myneni]

Post by Anton Ertl

Post by Krishna Myneni

Post by Anton Ertl

Post by Krishna Myneni
Why is 0 a valid argument to SET-ORDER (from the optional Search-Order
word set)? It can leave a Forth system in a non-recoverable state.

So what? There are lots of ways to put a Forth system in a
non-recoverable state.
...

By design? No.

Does it matter?

Yes, it matters. Not everyone uses Forth to develop and use turnkey
applications. Some of us rely on the Forth environment itself as the
application interface, where definitions in a precise search order *are*
the interface. Inadvertently emptying the search order and violating the
notion of a minimum search order would mean loss of data from a lengthy
computation or data acquisition.

--
Krishna

[dxf]

Post by Anton Ertl

Post by Krishna Myneni

Post by Krishna Myneni
Why is 0 a valid argument to SET-ORDER (from the optional Search-Order
word set)? It can leave a Forth system in a non-recoverable state.

So what?  There are lots of ways to put a Forth system in a
non-recoverable state.
...

By design? No.

Does it matter?

Yes, it matters. Not everyone uses Forth to develop and use turnkey applications. Some of us rely on the Forth environment itself as the application interface, where definitions in a precise search order *are* the interface. Inadvertently emptying the search order and violating the notion of a minimum search order would mean loss of data from a lengthy computation or data acquisition.

Under what circumstances is 0 SET-ORDER executed inadvertently?

[Krishna Myneni]

Post by dxf

Post by Anton Ertl

Post by Krishna Myneni

Post by Krishna Myneni
Why is 0 a valid argument to SET-ORDER (from the optional Search-Order
word set)? It can leave a Forth system in a non-recoverable state.

So what?  There are lots of ways to put a Forth system in a
non-recoverable state.
...

By design? No.

Does it matter?

Yes, it matters. Not everyone uses Forth to develop and use turnkey applications. Some of us rely on the Forth environment itself as the application interface, where definitions in a precise search order *are* the interface. Inadvertently emptying the search order and violating the notion of a minimum search order would mean loss of data from a lengthy computation or data acquisition.

Under what circumstances is 0 SET-ORDER executed inadvertently?

One example: assume you have a value containing the number of wordlists

0 value Nwid

and it is not properly set. Then doing,

wid1 wid2 ... widn Nwid SET-ORDER

--
KM

[Krishna Myneni]

...

Post by Krishna Myneni

Post by dxf
Under what circumstances is 0 SET-ORDER executed inadvertently?

One example: assume you have a value containing the number of wordlists
0 value Nwid
and it is not properly set. Then doing,
wid1 wid2 ... widn Nwid SET-ORDER

Beyond any particular case in which 0 SET-ORDER might occur, I am more
concerned with the fact that the standard does not guarantee a minimum
search order, from which it is useful to recover the search order
including it and the Forth word list. At the core, this is really the
problem.

--
Krishna

[minforth]

FORTH-WORDLIST 1 SET-ORDER should bring you "back to life".
IOW the question is whether FORTH-WORDLIST and SET-ORDER
should be findable even when the search-order is empty.
Probably classified as "implementation-defined option".

[a***@spenarnc.xs4all.nl]

Post by minforth
FORTH-WORDLIST 1 SET-ORDER should bring you "back to life".
IOW the question is whether FORTH-WORDLIST and SET-ORDER
should be findable even when the search-order is empty.
Probably classified as "implementation-defined option".

This is a practical necessity in a Forth. I opt for
ONLY FORTH
That results in the search order: ONLY FORTH
The word FORTH is in the ONLY wordlist i.e. minimal search order.
ONLY screens off all wordlists that may be present in the search order
and in ciforth it is itself a wordlist.

ONLY FORTH is a pretty surefire way to get the system in a
defined situation. This is almost traditional, albeit not standard.

Compared to ciforth
ORDER : ONLY FORTH
in gforth ONLY FORTH results in
ORDER : Root FORTH
in swiftforth it is the same, but the Root is not shown by ORDER
unless directly after ONLY.

vfxlin has an extra wordlistm but likewise you can get the system
under control with `` ONLY FORTH ''
ORDER: ROOT EXTERNALS FORTH

Groetjes Albert

[Krishna Myneni]

Post by minforth
FORTH-WORDLIST 1 SET-ORDER should bring you "back to life".
IOW the question is whether FORTH-WORDLIST and SET-ORDER
should be findable even when the search-order is empty.
Probably classified as "implementation-defined option".

The minimum search order contains FORTH-WORDLIST and SET-ORDER per the
standard. The question is whether or not the standard should actually
guarantee that this is always true.

It seems nonsensical to say there are zero wordlists in the search
order, but FORTH-WORDLIST and SET-ORDER are still findable.

--
KM

[minforth]

My "implementation-defined option" 0 SET-ORDER locks everyone out.
Too bad if you and I are one of them.

I want it that way. I don't like backdoors unless I created them
on purpose.

[Krishna Myneni]

Post by minforth
My "implementation-defined option" 0 SET-ORDER locks everyone out.
Too bad if you and I are one of them.
I want it that way. I don't like backdoors unless I created them
on purpose.

If the community has no issue with retaining 0 SET-ORDER then the
standard's wording should be revised to say that the minimum search
order is the empty search order, i.e. zero wordlists.

--
KM

[mhx]

Post by Krishna Myneni
If the community has no issue with retaining 0 SET-ORDER then the
standard's wording should be revised to say that the minimum search
order is the empty search order, i.e. zero wordlists.

IMHO, the committee should refrain from adding restrictions
that only serve to make systems 'not standard' because of non-issues.

-marcel

[Krishna Myneni]

Post by mhx

Post by Krishna Myneni
If the community has no issue with retaining 0 SET-ORDER then the
standard's wording should be revised to say that the minimum search
order is the empty search order, i.e. zero wordlists.

IMHO, the committee should refrain from adding restrictions
that only serve to make systems 'not standard' because of non-issues.
-marcel

Would you please state more clearly how this is related to the present
discussion? There is no proposal to add restrictions.

Currently we are discussing the merits and pitfalls of 0 SET-ORDER. I am
suggesting that a change in the wording of the standard is needed to
avoid the inference that a minimum search order is always present which
provides specific words listed in the standard.

--
Krishna

[a***@spenarnc.xs4all.nl]

Post by mhx

Post by Krishna Myneni
If the community has no issue with retaining 0 SET-ORDER then the
standard's wording should be revised to say that the minimum search
order is the empty search order, i.e. zero wordlists.

IMHO, the committee should refrain from adding restrictions
that only serve to make systems 'not standard' because of non-issues.

+1

Post by mhx
-marcel

[Ruvim]

Post by Krishna Myneni

Post by minforth
My "implementation-defined option" 0 SET-ORDER locks everyone out.
Too bad if you and I are one of them.
I want it that way. I don't like backdoors unless I created them
on purpose.

If the community has no issue with retaining 0 SET-ORDER then the
standard's wording should be revised to say that the minimum search
order is the empty search order, i.e. zero wordlists.

Do you mean it's confusing that the search order can contain fewer word
lists than the implementation defined "minimum search order"?

And if the term "minimum search order" is renamed to "small search
order" (as an example), will this solve the problem?


--
Ruvim

[Krishna Myneni]

Post by Ruvim

Post by Krishna Myneni

Post by minforth
My "implementation-defined option" 0 SET-ORDER locks everyone out.
Too bad if you and I are one of them.
I want it that way. I don't like backdoors unless I created them
on purpose.

If the community has no issue with retaining 0 SET-ORDER then the
standard's wording should be revised to say that the minimum search
order is the empty search order, i.e. zero wordlists.

Do you mean it's confusing that the search order can contain fewer word
lists than the implementation defined "minimum search order"?
And if the term "minimum search order" is renamed to "small search
order" (as an example), will this solve the problem?

I wonder if the original proposal for SET-ORDER meant to say "minimal"
instead of "minimum", for argument -1, thereby leading to the inference
that the words FORTH-WORDLIST and SET-ORDER always be present in the
search order. We need to check where else in the standard the term
"minimum search order" appears.

For the specification of SET-ORDER with argument -1 replacing "minimum"
with "minimal" would avoid some confusion.

--
Krishna

[dxf]

Post by minforth
My "implementation-defined option" 0 SET-ORDER locks everyone out.
Too bad if you and I are one of them.
I want it that way. I don't like backdoors unless I created them
on purpose.

If the community has no issue with retaining 0 SET-ORDER then the standard's wording should be revised to say that the minimum search order is the empty search order, i.e. zero wordlists.

Do you mean it's confusing that the search order can contain fewer word lists than the implementation defined "minimum search order"?
And if the term "minimum search order" is renamed to "small search order" (as an example), will this solve the problem?

I wonder if the original proposal for SET-ORDER meant to say "minimal" instead of "minimum", for argument -1, thereby leading to the inference that the words FORTH-WORDLIST and SET-ORDER always be present in the search order. We need to check where else in the standard the term "minimum search order" appears.
For the specification of SET-ORDER with argument -1 replacing "minimum" with "minimal" would avoid some confusion.

In the rationale A.16 the phrase "default search order" is used along with an explanation.

[dxf]

Post by dxf

...
I wonder if the original proposal for SET-ORDER meant to say "minimal" instead of "minimum", for argument -1, thereby leading to the inference that the words FORTH-WORDLIST and SET-ORDER always be present in the search order. We need to check where else in the standard the term "minimum search order" appears.
For the specification of SET-ORDER with argument -1 replacing "minimum" with "minimal" would avoid some confusion.

In the rationale A.16 the phrase "default search order" is used along with an explanation.

The more I look at it and what different systems return after -1 SET-ORDER the more
I'm confused as to what one is supposed to do after executing it - since in many
cases it's clear it is *not* the "default search order". As for 0 SET-ORDER the
situation is even more precarious given A.16. ISTM ANS could/should have done a
better job documenting this stuff as it was 'new practice'.

[Krishna Myneni]

Post by dxf

Post by minforth
My "implementation-defined option" 0 SET-ORDER locks everyone out.
Too bad if you and I are one of them.
I want it that way. I don't like backdoors unless I created them
on purpose.

If the community has no issue with retaining 0 SET-ORDER then the standard's wording should be revised to say that the minimum search order is the empty search order, i.e. zero wordlists.

Do you mean it's confusing that the search order can contain fewer word lists than the implementation defined "minimum search order"?
And if the term "minimum search order" is renamed to "small search order" (as an example), will this solve the problem?

I wonder if the original proposal for SET-ORDER meant to say "minimal" instead of "minimum", for argument -1, thereby leading to the inference that the words FORTH-WORDLIST and SET-ORDER always be present in the search order. We need to check where else in the standard the term "minimum search order" appears.
For the specification of SET-ORDER with argument -1 replacing "minimum" with "minimal" would avoid some confusion.

In the rationale A.16 the phrase "default search order" is used along with an explanation.

I'm searching at the Forth 2012 standard document and I don't find
"default search order" anywhere within it. Worse, I find the phrase,
"primitive search-order" used at the beginning of A.16, here and only
here. There is no explanation of what constitutes a primitive search order.

The phrase "minimum search order" is used five times in the document:
-- 16.4.1.1 Implementation-defined options
-- twice in the specification of SET-ORDER
-- twice in the specification of ONLY

In both the specification of SET-ORDER and ONLY, the standard states,
"The minimum search order shall include the words FORTH-WORDLIST and
SET-ORDER."

--
Krishna

[dxf]

Post by dxf

Post by minforth
My "implementation-defined option" 0 SET-ORDER locks everyone out.
Too bad if you and I are one of them.
I want it that way. I don't like backdoors unless I created them
on purpose.

If the community has no issue with retaining 0 SET-ORDER then the standard's wording should be revised to say that the minimum search order is the empty search order, i.e. zero wordlists.

Do you mean it's confusing that the search order can contain fewer word lists than the implementation defined "minimum search order"?
And if the term "minimum search order" is renamed to "small search order" (as an example), will this solve the problem?

I wonder if the original proposal for SET-ORDER meant to say "minimal" instead of "minimum", for argument -1, thereby leading to the inference that the words FORTH-WORDLIST and SET-ORDER always be present in the search order. We need to check where else in the standard the term "minimum search order" appears.
For the specification of SET-ORDER with argument -1 replacing "minimum" with "minimal" would avoid some confusion.

In the rationale A.16 the phrase "default search order" is used along with an explanation.

I'm searching at the Forth 2012 standard document and I don't find "default search order" anywhere within it. Worse, I find the phrase, "primitive search-order" used at the beginning of A.16, here and only here. There is no explanation of what constitutes a primitive search order.
-- 16.4.1.1 Implementation-defined options
-- twice in the specification of SET-ORDER
-- twice in the specification of ONLY
In both the specification of SET-ORDER and ONLY, the standard states, "The minimum search order shall include the words FORTH-WORDLIST and SET-ORDER."

What is one expected to do with 'FORTH-WORDLIST and SET-ORDER'? It's information like this
that's lacking, leaving it to the user's imagination. Nor will one get clarification from
200x since by this time principal users have a vested interest in leaving things ambiguous.

[a***@spenarnc.xs4all.nl]

Post by Krishna Myneni

Post by dxf

Post by minforth
My "implementation-defined option" 0 SET-ORDER locks everyone out.
Too bad if you and I are one of them.
I want it that way. I don't like backdoors unless I created them
on purpose.

If the community has no issue with retaining 0 SET-ORDER then the standard's wording should be revised to say that the minimum search

order is the empty search order, i.e. zero wordlists.

Post by dxf

Do you mean it's confusing that the search order can contain fewer word lists than the implementation defined "minimum search order"?
And if the term "minimum search order" is renamed to "small search order" (as an example), will this solve the problem?

I wonder if the original proposal for SET-ORDER meant to say "minimal" instead of "minimum", for argument -1, thereby leading to the

inference that the words FORTH-WORDLIST and SET-ORDER always be present in the search order. We need to check where else in the standard the
term "minimum search order" appears.

Post by dxf

For the specification of SET-ORDER with argument -1 replacing "minimum" with "minimal" would avoid some confusion.

In the rationale A.16 the phrase "default search order" is used along with an explanation.

I'm searching at the Forth 2012 standard document and I don't find "default search order" anywhere within it. Worse, I find the phrase,

"primitive search-order" used at the beginning of A.16, here and only here. There is no explanation of what constitutes a primitive search
order.

-- 16.4.1.1 Implementation-defined options
-- twice in the specification of SET-ORDER
-- twice in the specification of ONLY
In both the specification of SET-ORDER and ONLY, the standard states, "The minimum search order shall include the words FORTH-WORDLIST and

SET-ORDER."
What is one expected to do with 'FORTH-WORDLIST and SET-ORDER'? It's information like this
that's lacking, leaving it to the user's imagination. Nor will one get clarification from
200x since by this time principal users have a vested interest in leaving things ambiguous.

At least to me this is clear.
FORTH-WORDLIST 1 SET-ORDER
is supposed to get Forth under control.
Traditionally done with
ONLY FORTH

Groetjes Albert

[dxf]

Post by a***@spenarnc.xs4all.nl

Post by Krishna Myneni

...
In both the specification of SET-ORDER and ONLY, the standard states, "The minimum search order shall include the words FORTH-WORDLIST and

SET-ORDER."
What is one expected to do with 'FORTH-WORDLIST and SET-ORDER'? It's information like this
that's lacking, leaving it to the user's imagination. Nor will one get clarification from
200x since by this time principal users have a vested interest in leaving things ambiguous.

At least to me this is clear.
FORTH-WORDLIST 1 SET-ORDER
is supposed to get Forth under control.
Traditionally done with
ONLY FORTH

Won't that mess up the "minimum search order" scenario described in A.16:

"In some systems the interpretation of numeric literals is controlled by including
pseudo word lists that recognize numbers at the end of the search order. This
technique is accommodated by the default search order behavior of SET-ORDER when
given an argument of -1."

[a***@spenarnc.xs4all.nl]

Post by Krishna Myneni

Post by Ruvim

Post by Krishna Myneni

Post by minforth
My "implementation-defined option" 0 SET-ORDER locks everyone out.
Too bad if you and I are one of them.
I want it that way. I don't like backdoors unless I created them
on purpose.

If the community has no issue with retaining 0 SET-ORDER then the
standard's wording should be revised to say that the minimum search
order is the empty search order, i.e. zero wordlists.

Do you mean it's confusing that the search order can contain fewer word
lists than the implementation defined "minimum search order"?
And if the term "minimum search order" is renamed to "small search
order" (as an example), will this solve the problem?

I wonder if the original proposal for SET-ORDER meant to say "minimal"
instead of "minimum", for argument -1, thereby leading to the inference
that the words FORTH-WORDLIST and SET-ORDER always be present in the
search order. We need to check where else in the standard the term
"minimum search order" appears.
For the specification of SET-ORDER with argument -1 replacing "minimum"
with "minimal" would avoid some confusion.

I have a minimal system and opt out of the "optional search order wordset".
So SET-ORDER is not present.
What gives?

Post by Krishna Myneni
--
Krishna

[sjack]

Post by a***@spenarnc.xs4all.nl
I have a minimal system and opt out of the "optional search order wordset".
So SET-ORDER is not present.
What gives?

I long back opt out the search order wordset. It just gave me
management concerns. I use SCRs instead and keep requrements
external to the files. Life has been much smoother since.

[dxf]

Post by sjack

Post by a***@spenarnc.xs4all.nl
I have a minimal system and opt out of the "optional search order wordset".
So SET-ORDER is not present.
What gives?

I long back opt out the search order wordset. It just gave me
management concerns. I use SCRs instead and keep requrements
external to the files. Life has been much smoother since.

Yep. Went back to pre ALSO/ONLY schemes. Every 'feature' just
creates more things to manage.

'Forthers have complicated every simple gift of Moore' - Diogenes

[Ruvim]

Post by Krishna Myneni

Post by Ruvim

Post by Krishna Myneni
If the community has no issue with retaining 0 SET-ORDER then the
standard's wording should be revised to say that the minimum search
order is the empty search order, i.e. zero wordlists.

Do you mean it's confusing that the search order can contain fewer
word lists than the implementation defined "minimum search order"?
And if the term "minimum search order" is renamed to "small search
order" (as an example), will this solve the problem?

I wonder if the original proposal for SET-ORDER meant to say "minimal"
instead of "minimum", for argument -1, thereby leading to the inference
that the words FORTH-WORDLIST and SET-ORDER always be present in the
search order. We need to check where else in the standard the term
"minimum search order" appears.

In Forth-94:

<http://lars.nocrew.org/dpans/dpans16.htm>
<http://lars.nocrew.org/dpans/dpansa16.htm>
<http://lars.nocrew.org/dpans/a0002.htm>

Post by Krishna Myneni
For the specification of SET-ORDER with argument -1 replacing "minimum"
with "minimal" would avoid some confusion.

Wiktionary says that they are synonyms:
<https://en.wiktionary.org/wiki/minimum#Adjective>


--
Ruvim

[Krishna Myneni]

...

Post by Krishna Myneni
I wonder if the original proposal for SET-ORDER meant to say "minimal"
instead of "minimum", for argument -1, thereby leading to the
inference that the words FORTH-WORDLIST and SET-ORDER always be
present in the search order. We need to check where else in the
standard the term "minimum search order" appears.

  <http://lars.nocrew.org/dpans/dpans16.htm>
  <http://lars.nocrew.org/dpans/dpansa16.htm>
  <http://lars.nocrew.org/dpans/a0002.htm>

Post by Krishna Myneni
For the specification of SET-ORDER with argument -1 replacing
"minimum" with "minimal" would avoid some confusion.

<https://en.wiktionary.org/wiki/minimum#Adjective>

That seems to be the case with the Oxford dictionary as well. My
understanding of minimum is the smallest possible, and minimal implies a
small size (but not necessarily the smallest).

So, who knows what they were thinking when the standard was written
because the clear statement that "the minimum search order shall include
the words ...", which appears in the spec for SET-ORDER and for ONLY
clears contradicts the allowance for 0 SET-ORDER.

The language needs to be fixed.

I remember when I was implementing the Search Order word set in kForth,
the phrase "the minimum search order shall include the words ..." but
the contradiction with 0 SET-ORDER didn't register with me at the time.

--
Krishna