Groups | Search | Server Info | Login | Register

Groups > comp.lang.forth > #134173

Re: 0 vs. translate-none

Show all headers | View raw

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

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

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