Sujet : Recognizer protocol (was: 0 SET-ORDER why?)
De : ruvim.pinka (at) *nospam* gmail.com (Ruvim)
Groupes : comp.lang.forthDate : 28. Jun 2024, 23:27:29
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <v5ndch$3d9d8$1@dont-email.me>
References : 1 2 3 4 5
User-Agent : Mozilla Thunderbird
On 2024-06-28 23:45,
albert@spenarnc.xs4all.nl wrote:
In article <v5m2po$3811n$2@dont-email.me>,
Ruvim <ruvim.pinka@gmail.com> wrote:
On 2024-06-27 08:14, Gerry Jackson wrote:
[...]
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.
My rationale:
"Recognizer protocol", 2020-07-04
<
news:rdpu54$pfn$1@dont-email.me>
<
https://groups.google.com/g/comp.lang.forth/c/yuNZEvq8EqA/m/-FcvRcwRAQAJ>
Moreover the items would have to be the same in
interpret and compilation mode.
Agreed.
Rationale:
1. In most use cases the result of recognizing does not depend on STATE
(and when it depends, like in cmForth, it can be made independent).
2. One useful thing about recognizers is that they can be used for more than just the purpose of lexeme translation. If we would need to only translate lexemes (i.e., to compile or interpret a lexeme depending on STATE) — no need to separate the step of recognizing.
3. If we recognize a lexeme not for further immediate translation, and the result may depend on STATE, we will need to change STATE before recognizing (or use some helpers to indicate our intention). This only complicates some use cases and does not simplify anything.
At least as a starting point, otherwise Forth degenerates to a
tangled web of special purpose interpreters.
-- Ruvim