In article <20250920103435.00002fbe@tin.it>,
peter wrote:
>On Sat, 20 Sep 2025 07:25:54 GMT
>anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>
>> peter writes:
>> >On lxf64 each individual recognizer returns 0 when no match was found.
>> >The last recognizer to be tested is REC-ABORT (same as your REC-NONE).
>>
>> REC-NONE is the neutral element of recognizer sequences, i.e., as far
>> as the sequence is concerned, a noop. You can prepend REC-NONE to a
>> recognizer sequence and the sequence will produce the same result.
>> The implementation of REC-NONE is:
>>
>> : rec-none ( c-addr u -- translation )
>> 2drop translate-none ;
>>
>> I doubt that your REC-ABORT works like that. My guess is that your
>> REC-ABORT is:
>>
>> : rec-abort -13 throw ;
>
>:NONAME -13 throw ;
>dup-t
>dup-t
>CREATE TRANSLATE-ABORT
>,-d-t ,-d-t ,-d-t
>
>
>: REC-ABORT ( addr len -- nt)
> >msg translate-abort ;
>
>The -t and -d-t endings are due to this being metacompiled
>>msg saves the string to be able to print the name in the abort message
>
>>
>> and I will work with that guess in the folloing.
>>
>> >As a consequence REC-FORTH will never fail!
>>
>> In the proposal, any recognizer and recognizer sequence, including
>> that in REC-FORTH, can have TRANSLATE-NONE as a result, which
>> indicates that the recognizer (sequence) did not recognize the string.
>>
>> >The interpret word thus becomes very simple
>> >
>> >M: STATE-TRANSLATING ( trans -- ) \ get the right xt for the
current state
>> > 2 state @ + cells+ @ execute ;
>> >
>> >: INTERPRET2 ( -- )
>> > begin parse-name
>> > dup while
>> > forth-recognize state-translating
>> > repeat 2drop
>> > ?stack ;
>>
>> The same implementation can be used with the proposal (but it calls
>> FORTH-RECOGNIZE by a new name: REC-FORTH) and TRANSLATE-NONE.
>> Compared to what I presented, the order of xts in the
>> TRANSLATE-... tables is reversed, so POSTPONING would become even
>> simpler:
>>
>> : POSTPONING ( translation -- )
>> @ execute ;
>
>: postpone ( "name" -- )
> parse-name forth-recognize @ execute ; immediate
>
>>
>> One difference is that, for an unrecignized string, the -13 throw is
>> done later, when performing the action of the translation.
>>
>> The benefit of having TRANSLATE-NONE and doing the -13 throw in its
>> actions, instead of hard-coded in REC-FORTH is that REC-FORTH contains
>> just another recognizer sequence, that recognizer sequences behave
>> like recognizers, and thus are nestable, and that you can write code
>> like
>>
>> ( c-addr u ) rec-something ( translation ) postponing
>>
>> and it will work without you having to put REC-ABORT at the end of
>> REC-SOMETHING.
>>
>> However, the current proposal does not propose to standardize
>> POSTPONING etc., but leaves it to the standard text interpreter and
>> standard POSTPONE to perform the translation actions. So, as long as
>> we don't standardize these words, one could also have a recognizer
>> sequence
>>
>> ' rec-abort ' rec-forth 2 recognizer-sequence: rec-forth-abort
>>
>> and let the text interpreter and POSTPONE call REC-FORTH-ABORT instead
>> of REC-FORTH. But if we want to leave the option open to standardize
>> POSTPONING etc. in the future, the proposed approach is more flexible.
>>
>> - anton
>
>Apart from the names that has changed (I have not updated them yet) I see only
>minor differences. One being the individual recognizer returning 0 on fail.
>
>I implemented yur proposal from February and it has worked as expected.
>The float recognizer has been a cleanup removing deferred words and now done
>instead when the float package is included.
>
>I am using a linked list of recognizers but that is only an implementation
detail.
>I do not see that the "standard" would mandate an array.
>
>I have introduce a vocabulary like word for managing the recognizers
>
>It looks like
>
>' rec-local recognizer: Locals-recognizer
>
>This does 3 things
>
>- It gives the recognizer a name.
>
>- It inserts the recognizer in the list just behind the number recognizers
>
>- Executing it moves the recognizers to the top of the list
>
>I have also adjuster ORDER to also chow the recognizers
>
>order
> Order: $0070´01C0 Forth
> $0070´01E8 Root
>
>Current: $0070´01C0 Forth
>
>Loaded recognizers:
> $0070´18E8 Locals-recognizer
> $0070´0648 Word-recognizer
> $0070´0620 Number-recognizer
> $0070´1C88 Float-recognizer
> $0070´1D28 String-recognizer
> $0070´19B0 Tick-recognizer
> $0070´1948 To-recognizer
> $0070´1970 To2-recognizer
> $0070´1A20 Only-recognizer
> $0070´0600 Abort not found
>
>ok
>
>BR
>Peter
In ciforth all "recognizers" are prefixes in the ONLY wordlist,
during startup (You can define recognizers yourself in any wordlist).
They are modular, they have no connection and are governed
by the regular search order.
0-9 and - + recognizes numbers
^ & recognizes control and regular chars
' recognizes a name and turns it in an address that identifies
the word
" recognizes strings
All these leave a constant.
It is easy to add
{ An anonymous code sequence that can be EXECUTEd.
Also this leave a constant. No need for a distinction between
:NONAME and [: .
$ 0x # % 00 To recognizes numbers in a certain base, hex, dec, bin, octal
Change number prefix to include floating point.
All this is accomplised by a PREFIX flag (compare IMMEDIATE)
and a provision that advances the interpreter pointer by
the length of the prefixes, not by the length of the word passed
to it.
It is believable that the system presented above is more powerful,
but I love to see examples what it can do that warrant the
complexity. Also I love to see if the examples can't be
done with my simpler setup.
Recently I presented the Roman number prefix. How does
that look in the recognizer presented.
Groetjes Albert
--
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
