0 SET-ORDER hoses a system?

[SirWumpus]

0 SET-ORDER will empty/clear the search order. This would appear leave the system in a non-functional state, since FIND-NAME and FIND apply the current search order with no mention of a fall-back position to the FORTH-WORDLIST in the event there is no order.

While -1 SET-ORDER resets to a minimum search order, once the search order is empty, its not possible to reset it. Given the wording, I do not see an escape clause. What am I missing?

[mgcaret]

It is called out as an ambiguous condition.

In OF816, I search the compilation word list in this situation, so that if OF816 is compiled without the search order word set, it simply operates with an empty search order.

[ruv]

While -1 SET-ORDER resets to a minimum search order, once the search order is empty, its not possible to reset it.

It is possible, but not interactively. A test:

t{
  :noname
    get-order n>r \ save the search order
    0 set-order \ at this point the search order is empty
    \ no words shall be foundable 
    c" set-order" find nip 0<> ( flag1 ) \ this word shall not be found
    -1 set-order \ this shall set the minimum search order
    c" set-order" find nip 0<> ( flag2 ) \ now this word shall be found
    nr> set-order \ restore the search order
  ; execute
->
  false true
}t

Given the wording, I do not see an escape clause. What am I missing?

The section 4.2.2 Other program documentation says that a standard program shall document "whether a Standard System exists after the program is loaded".

If a program leaves the search order empty, the system is not a standard system anymore, so no standard requirements can be applied.

On the other hand, there are millions of ways to put a Forth system into an inoperable state. Interactively executing 0 set-order is one such way.

[SirWumpus]

Why would one standardise a way to disable a Forth system? I do not see its utility, unless its intended to disable interactive Forth for a running Forth program in production.

[ruv]

This was discussed in comp.lang.forth recently.

Why would one standardise a way to disable a Forth system?

wordlist 1 set-order and forth-wordlist 1 set-order previous are other standard ways to disable a Forth system.

In general, a defined behavior is better than undefined. In this case this costs nothing.

What do you think would be a better behavior in this case (i.e., for 0 set-order)?

I do not see its utility, unless its intended to disable interactive Forth for a running Forth program in production.

It is a one of possible use cases. Another use case is to interpret numbers from an untrusted source using evaluate.

For example:

: string-to-number ( sd.number -- n )
  depth 2 - >r  get-order n>r  0 set-order
  ['] evaluate ['] execute-interpreting catch
  nr> set-order  abort" not a number"
  depth r> - 1 <> abort" not a single-cell number"
;