Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Krishna Myneni <krishna.myneni@ccreweb.org>
Newsgroups: comp.lang.forth
Subject: Re: 0 SET-ORDER why?
Date: Thu, 27 Jun 2024 14:09:52 -0500
Organization: A noiseless patient Spider
Lines: 77
Message-ID: <v5kde0$2sasd$1@dont-email.me>
References: <v5fjkr$1p13i$1@dont-email.me>
 <2024Jun26.094910@mips.complang.tuwien.ac.at> <667bd654$1@news.ausics.net>
 <v5h5h6$2565d$1@dont-email.me> <v5ioud$2ii4l$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 27 Jun 2024 21:09:53 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="3e1155ef3c14984d719ad25c26716b5d";
	logging-data="3025805"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18gp+NMecqkL3hXvw4/zNNn"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:k2Z5aleuPIZoGysMUiKxZW64x6g=
Content-Language: en-US
In-Reply-To: <v5ioud$2ii4l$1@dont-email.me>
Bytes: 3589

On 6/26/24 23:14, Gerry Jackson wrote:
> On 26/06/2024 14:36, Ruvim wrote:
>> One possible use case:
>>
>>    : 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.
> 
>  > 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
>  >    ;
> 
> 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)