Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #135096

Re: ciforth model

Show all headers | View raw

peter <peter.noreply@tin.it> writes:
>On Sat, 23 May 2026 18:12:20 GMT
>anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>> peter <peter.noreply@tin.it> writes:
>> >The other interesting change I did was to put in a link to translate-name.
>> >Each word now knows how to interpret, compile and postpone itself!
>> >
>> >I have now 3 standard word types
>> >translate-name
>> >translate-name-immediate
>> >translate-name-macro
>> >
>> >This takes away all checks of the flag and following conditionals.
>> >I could actually remove the flag byte.
>> 
>> In Gforth we did this by making the implementations of NAME>INTERPRET
>> and NAME>COMPILE word-specific:
>> 
>> Words with default compilation semantics have DEFAULT-NAME>COMP als
>> implementation, immediate words have IMM>COMP as implementation, and
>> other words (e.g., S") have other implementations.
>> 
>> \ the actual implementation is a bit different, but this is the
>> \ easier-to-understand version.
>> : default-name>comp ( nt -- xt1 xt2 )
>>   name>interpret ['] compile, ;
>> 
>> : imm>comp ( nt -- xt1 xt2 )
>>   name>interpret ['] execute ;
>
>I studied your linked document and slides a understood it worked 
>something like that. Seeing your VT table gave me the idea to
>put in a link to the translate record

Nowadays we call the table HM, for header methods.  VT is too generic.
In development Gforth, you can see the header methods for a word by
using .HM on its NT.  E.g.:

``+ .hm 
opt:     $7FA3C4A363D8 
to:      n/a 
extra:   $0 
>int:    default-name>int 
>comp:   default-name>comp 
>string: named>string 
>link:   named>link

>: NAME>COMPILE   ( nt -- w xt )
>    dup nt>trans l@ cell+ @ ;

That's interesting.  Instead of defining TRANSLATE-NAME's compilation
action in terms of NAME>COMPILE, you put the differences between
different names into TRANSLATE-NAME, and implement NAME>COMPILE by
accessing the internals of TRANSLATE-NAME.

>With the 3 translate-name-xxx all the flag testing is gone!

Yes, we also eliminated nearly all flags with the new header format.
We kept a compile-only flag (for warning about compile-only words),
and added an obsolete flag (for warning about words that are going to
be removed from a future Gforth), because warnings do not introduce
complicated control flow.

>The ability to set a specific translation record for the 
>state smart words comes as an extra benefit.

I guess you mean words with non-immediate non-default compilation
semantics, and yes, being able to tell the Forth system how it should
treat such a word at text interpretation time avoids the unpleasant
surprises that STATE-smart immediate words (that try to figure out at
run-time by inspecting STATE what they should do, but the STATE at
run-time does not provide information about whether their
interpretation semantics or compilation semantics is performed).

>>To really integrate the recognizers well I made REC-NAME the
>primary name finding function. Fnd-name is then defined as:
>
>: FIND-NAME ( caddr u -- ht | 0)
>	rec-name dup if drop then ;
>
>Translate-none returns a null pointer in my system.

Yes, we have written about the idea of unifying recognizers and
wordlists [paysan20].  Development Gforth implements this idea.  E.g.,
if you do

s" dup" forth-wordlist execute

you find a translation on the stack, consisting of the nt of DUP and
of TRANSLATE-NAME.  The implementations of FIND-NAME-IN and FIND-NAME
are:

: find-name-in  ( c-addr u wid -- nt | 0 ) \ gforth
    execute translate-none = IF  0  THEN ;

: find-name ( c-addr u -- nt | 0 ) \ gforth
    ['] rec-name find-name-in ;

The latter makes use of the fact that the recognizer sequence in
REC-NAME can be treated as wordlist.  That relies on the fact that
only wordlists are in the search order (and the search-order is in the
deferred word REC-NAME).  If you put, e.g., REC-NUMBER into the search
order, the result will be that FIND-NAME will push a single-cell or
double-cell number when you pass it something that is recognized by
that REC-NUMBER.  But that's the usual fare in Forth, if you hold it
wrong, it produces the wrong result.

The current proposal proposes the nested recognizers, but does not
require wordlists to work as recognizers.

@InProceedings{paysan20,
  author =       {Bernd Paysan and M. Anton Ertl},
  title =        {The Grand Recognizer Unification},
  crossref =     {euroforth20},
  pages =        {19--22},
  url =          {http://www.euroforth.org/ef20/papers/paysan.pdf},
  url-slides =   {http://www.euroforth.org/ef20/papers/paysan-slides.pdf},
  video =        {https://www.youtube.com/watch?v=VUi6uYqIbTI},
  OPTnote =      {not refereed},
  abstract =     {There is an obvious similarity between the search
                  order and a recognizer sequence, which has led to
                  similarities in proposed words (e.g.,
                  \code{get-recognizer} is modeled on
                  \code{get-order}).  By turning word lists into
                  recognizers, we unify these concepts.  We also turn
                  recognizer sequences (and be extension the search
                  order) into a recognizer, which allows nestable
                  recognizer sequences and wordlist sequences in the
                  search order.  The implementation becomes simpler,
                  too.}
}
@Proceedings{euroforth20,
  title = 	 {36th EuroForth Conference},
  booktitle = 	 {36th EuroForth Conference},
  year = 	 {2020},
  key =		 {EuroForth'20},
  url =          {http://www.euroforth.org/ef20/papers/proceedings.pdf}
}

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: https://forth-standard.org/
EuroForth 2025 proceedings: http://www.euroforth.org/ef25/papers/

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

Thread

ciforth model albert@spenarnc.xs4all.nl - 2026-04-16 15:38 +0200
  Re: ciforth model dxf <dxforth@gmail.com> - 2026-04-17 11:44 +1000
    Re: ciforth model anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-17 07:29 +0000
      Re: ciforth model albert@spenarnc.xs4all.nl - 2026-04-17 12:10 +0200
        Re: ciforth model anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-18 10:26 +0000
          Re: ciforth model peter <peter.noreply@tin.it> - 2026-04-18 18:11 +0200
          Re: ciforth model albert@spenarnc.xs4all.nl - 2026-04-18 20:57 +0200
            Re: ciforth model anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-19 11:08 +0000
              Re: ciforth model albert@spenarnc.xs4all.nl - 2026-04-20 13:39 +0200
          Re: ciforth model peter <peter.noreply@tin.it> - 2026-05-21 10:28 +0200
            Re: ciforth model minforth <minforth@gmx.net> - 2026-05-22 12:04 +0200
            Re: ciforth model anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-23 18:12 +0000
              Re: ciforth model peter <peter.noreply@tin.it> - 2026-05-23 23:09 +0200
              Re: ciforth model peter <peter.noreply@tin.it> - 2026-05-24 10:07 +0200
                Re: ciforth model anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-25 13:34 +0000
                Re: ciforth model peter <peter.noreply@tin.it> - 2026-05-27 10:42 +0200
      Re: ciforth model Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-21 19:39 +0200
      Re: ciforth model albert@spenarnc.xs4all.nl - 2026-04-22 22:48 +0200
        Re: ciforth model Paul Rubin <no.email@nospam.invalid> - 2026-04-24 10:38 -0700
          Re: ciforth model albert@spenarnc.xs4all.nl - 2026-04-25 11:54 +0200
            Re: ciforth model Paul Rubin <no.email@nospam.invalid> - 2026-04-25 13:22 -0700
              Re: ciforth model albert@spenarnc.xs4all.nl - 2026-04-26 14:05 +0200
      hashing for Forth dictionaries and address books (was Re: ciforth model) Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-01 15:09 -0300
  Re: ciforth model Paul Rubin <no.email@nospam.invalid> - 2026-04-17 00:27 -0700
    Re: ciforth model albert@spenarnc.xs4all.nl - 2026-04-17 12:13 +0200

csiph-web