Path: ...!feed.opticnetworks.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Gerry Jackson <do-not-use@swldwa.uk>
Newsgroups: comp.lang.forth
Subject: Re: 0 SET-ORDER why?
Date: Thu, 27 Jun 2024 23:08:19 +0100
Organization: A noiseless patient Spider
Lines: 116
Message-ID: <v5knsk$2tvp8$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>
 <v5kde0$2sasd$1@dont-email.me> <v5ke5a$2sasd$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 28 Jun 2024 00:08:20 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0158eae55167e025db00982c7364782a";
	logging-data="3079976"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/vpkTouKEkVY5Q8fS6hI0mYwKZVkqro1Q="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:F6kF1oLG/4S3ukgFf3/Q7rhYoZU=
Content-Language: en-GB
In-Reply-To: <v5ke5a$2sasd$2@dont-email.me>
Bytes: 5130

On 27/06/2024 20:22, Krishna Myneni wrote:
> 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.
>>

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

>> 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.

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

>>
>> 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