Groups | Search | Server Info | Login | Register
Groups > comp.lang.forth > #134175
| From | peter <peter.noreply@tin.it> |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: 0 vs. translate-none |
| Date | 2025-09-20 19:08 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <20250920190827.00003f6d@tin.it> (permalink) |
| References | (2 earlier) <2025Sep19.174547@mips.complang.tuwien.ac.at> <20250919193929.00000ec0@tin.it> <2025Sep20.092554@mips.complang.tuwien.ac.at> <20250920103435.00002fbe@tin.it> <2025Sep20.180803@mips.complang.tuwien.ac.at> |
On Sat, 20 Sep 2025 16:08:03 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
> peter <peter.noreply@tin.it> writes:
> >On Sat, 20 Sep 2025 07:25:54 GMT
> >anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
> >
> >> peter <peter.noreply@tin.it> 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).
> >>=20
> >> 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:
> >>=20
> >> : rec-none ( c-addr u -- translation )
> >> 2drop translate-none ;
> >>=20
> >> I doubt that your REC-ABORT works like that. My guess is that your
> >> REC-ABORT is:
> >>=20
> >> : rec-abort -13 throw ;
> >
> >:NONAME -13 throw ;=20
> >dup-t
> >dup-t
> >CREATE TRANSLATE-ABORT
> >,-d-t ,-d-t ,-d-t
> >
> >
> >: REC-ABORT ( addr len -- nt)
> > >msg translate-abort ;
>
> Ok, your TRANSLATE-ABORT is TRANSLATE-NONE, and your REC-ABORT is
> REC-NONE.
>
> >>msg saves the string to be able to print the name in the abort message
>
> Might be cleaner than Gforth's current mechanism (I don't remember how
> that works).
>
> >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.
>
> So the usual recognizers return 0 for not-recognized, but REC-FORTH
> returns TRANSLATE-NONE. Interesting twist. What about other
> recognizer sequences?
There are no other recognizer sequences. I have not found a use case for that.
I guess I would implement them to also return TRANSLATE-NONE.
>
> >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.
>
> The standard does not mandate any particular implementation of
> REC-FORTH or of recognizer sequences.
>
> >
> >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
>
> But before other recognizers behind the number recognizers?
Yes
>
> >- Executing it moves the recognizers to the top of the list
>
> I am confused. Under what circumstances does the "insert just behind"
> happen, and when "move to the top"?
Insert behind only when the recognizer is created. To still have a standard system.
To the top in all other cases.
ONLY for example contains
: ONLY ( -- )
1 #order ! root-wordlist context !
number-recognizer word-recognizer locals-recognizer ;
>
> And what scenario do you have in mind that makes this behaviour
> useful?
It has been usefull when testing new recognizers.
Otherwise I never change the ordering
Peter
>
> - anton
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar
0 vs. translate-none anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-17 16:53 +0000
Re: 0 vs. translate-none minforth <minforth@gmx.net> - 2025-09-19 12:24 +0200
Re: 0 vs. translate-none anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-19 15:45 +0000
Re: 0 vs. translate-none peter <peter.noreply@tin.it> - 2025-09-19 19:39 +0200
Re: 0 vs. translate-none anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-20 07:25 +0000
Re: 0 vs. translate-none peter <peter.noreply@tin.it> - 2025-09-20 10:34 +0200
Re: 0 vs. translate-none anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-20 16:08 +0000
Re: 0 vs. translate-none peter <peter.noreply@tin.it> - 2025-09-20 19:08 +0200
Re: 0 vs. translate-none anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-20 17:57 +0000
Re: 0 vs. translate-none peter <peter.noreply@tin.it> - 2025-09-20 20:55 +0200
Re: 0 vs. translate-none anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-21 12:33 +0000
Re: 0 vs. translate-none peter <peter.noreply@tin.it> - 2025-09-21 18:39 +0200
Re: 0 vs. translate-none anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-23 17:25 +0000
Re: 0 vs. translate-none peter <peter.noreply@tin.it> - 2025-09-23 22:25 +0200
Re: 0 vs. translate-none albert@spenarnc.xs4all.nl - 2025-09-24 01:15 +0200
Re: 0 vs. translate-none anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-24 06:26 +0000
Re: 0 vs. translate-none albert@spenarnc.xs4all.nl - 2025-09-21 10:37 +0200
Re: 0 vs. translate-none minforth <minforth@gmx.net> - 2025-09-21 13:56 +0200
Re: 0 vs. translate-none albert@spenarnc.xs4all.nl - 2025-09-21 14:44 +0200
Re: 0 vs. translate-none minforth <minforth@gmx.net> - 2025-09-21 17:46 +0200
Re: 0 vs. translate-none anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-23 17:23 +0000
Re: 0 vs. translate-none minforth <minforth@gmx.net> - 2025-09-23 22:38 +0200
Re: 0 vs. translate-none anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-24 06:38 +0000
Re: 0 vs. translate-none minforth <minforth@gmx.net> - 2025-09-24 09:39 +0200
Re: 0 vs. translate-none albert@spenarnc.xs4all.nl - 2025-09-24 10:28 +0200
Re: 0 vs. translate-none minforth <minforth@gmx.net> - 2025-09-24 10:44 +0200
Re: 0 vs. translate-none minforth <minforth@gmx.net> - 2025-09-24 10:36 +0200
Re: 0 vs. translate-none anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-21 12:50 +0000
Re: 0 vs. translate-none albert@spenarnc.xs4all.nl - 2025-09-21 21:39 +0200
Re: 0 vs. translate-none anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-22 06:56 +0000
Re: 0 vs. translate-none albert@spenarnc.xs4all.nl - 2025-09-22 10:09 +0200
Re: 0 vs. translate-none anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-22 08:39 +0000
Re: 0 vs. translate-none albert@spenarnc.xs4all.nl - 2025-09-22 23:03 +0200
Re: 0 vs. translate-none anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-23 17:00 +0000
Re: 0 vs. translate-none albert@spenarnc.xs4all.nl - 2025-09-24 00:41 +0200
Re: 0 vs. translate-none dxf <dxforth@gmail.com> - 2025-09-24 13:57 +1000
Re: 0 vs. translate-none anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-24 06:45 +0000
Re: 0 vs. translate-none dxf <dxforth@gmail.com> - 2025-09-25 15:22 +1000
Re: 0 vs. translate-none anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-25 06:36 +0000
Re: 0 vs. translate-none albert@spenarnc.xs4all.nl - 2025-09-25 13:00 +0200
Re: 0 vs. translate-none anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-29 05:54 +0000
Re: 0 vs. translate-none albert@spenarnc.xs4all.nl - 2025-09-29 11:03 +0200
Re: 0 vs. translate-none anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-29 16:27 +0000
Re: 0 vs. translate-none dxf <dxforth@gmail.com> - 2025-09-26 10:56 +1000
Re: 0 vs. translate-none Hans Bezemer <the.beez.speaks@gmail.com> - 2025-09-26 17:09 +0200
Re: 0 vs. translate-none dxf <dxforth@gmail.com> - 2025-09-29 00:42 +1000
Re: 0 vs. translate-none Hans Bezemer <the.beez.speaks@gmail.com> - 2025-09-30 18:15 +0200
Re: 0 vs. translate-none dxf <dxforth@gmail.com> - 2025-10-01 14:10 +1000
Re: 0 vs. translate-none Hans Bezemer <the.beez.speaks@gmail.com> - 2025-10-02 15:48 +0200
Re: 0 vs. translate-none Ruvim <ruvim.pinka@gmail.com> - 2025-09-26 02:19 +0400
Re: 0 vs. translate-none Ruvim <ruvim.pinka@gmail.com> - 2025-09-27 13:43 +0400
csiph-web