Newsgroups: comp.lang.forth
References: <v5fjkr$1p13i$1@dont-email.me> <v5h5h6$2565d$1@dont-email.me> <v5ioud$2ii4l$1@dont-email.me> <v5m2po$3811n$2@dont-email.me>
From: albert@spenarnc.xs4all.nl
Subject: Re: 0 SET-ORDER why?
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: albert@cherry.(none) (albert)
Message-ID: <nnd$7870c3ff$439130c9@777992005d4c8114>
Organization: KPN B.V.
Date: Fri, 28 Jun 2024 21:45:38 +0200
Path: ...!weretis.net!feeder8.news.weretis.net!2.eu.feeder.erje.net!feeder.erje.net!feed.abavia.com!abe004.abavia.com!abp003.abavia.com!news.kpn.nl!not-for-mail
Lines: 93
Injection-Date: Fri, 28 Jun 2024 21:45:38 +0200
Injection-Info: news.kpn.nl; mail-complaints-to="abuse@kpn.com"
Bytes: 4063

In article <v5m2po$3811n$2@dont-email.me>,
Ruvim  <ruvim.pinka@gmail.com> wrote:
>On 2024-06-27 08: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.
>
>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.
>
>
>>
>> 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>
>
>
>> 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
>>  >    ;
>
>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
>   ;
>
>
>>
>> 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.
>
>Although, this approach can be used to *implement* SOME-RECOGNISER.
>
>
>--
>Ruvim
-- 
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring.            - the Wise from Antrim -