Path: ...!news.mixmin.net!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:22:18 -0500
Organization: A noiseless patient Spider
Lines: 87
Message-ID: <v5ke5a$2sasd$2@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>
 <v5kde0$2sasd$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:22:19 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="3e1155ef3c14984d719ad25c26716b5d";
	logging-data="3025805"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/r+P6a+yWFEQr+zk22hc+j"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:ziXUS7qO5IkuVqjOpSb2sLVv2gs=
Content-Language: en-US
In-Reply-To: <v5kde0$2sasd$1@dont-email.me>
Bytes: 4181

On 6/27/24 14:09, Krishna Myneni wrote:
> 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.
> 

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