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

Groups > comp.lang.forth > #135102

Re: ciforth model

Show key headers only | View raw

On Mon, 25 May 2026 13:34:48 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

> 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.
 
My first reaction when the idea of recognizers were presented was that
they should be combined with word-lists and search order. I have never
followed up on that idea. Interesting that you are doing it.

Instead in the latest version rec-name has been slim lined to avoid
unnecessary work. In LXF64 I store the names in uppercase. At find time
the parsed string also needs to be upper cased and a hash calculated.
I now do this one time and use the result for all comparisons in the 
different word-lists rec-name is defined as

: REC-NAME  ( c-addr n --  0| ht translator )
    dup 0= if nip exit then                 \ empty string
    #order @ 0= if 2drop 0 exit then        \ empty order
    copy-upcase-hash                        \ hash  namestring in namebuf
	#order @    
	
	begin
		dup
	while
		1- >r
		dup                         \ hash hash R:ordernr
		r@ cells context + @ swap   \ hash wid hash
        hash>bucket @ namebuf swap          \ hash name bucket
        search-bucket2                      \ hash nt|0
		dup
		if r>drop nip dup nt>trans l@ exit then      
		drop r>
	repeat 
    nip ;

copy-upcase-hash takes care of the work in just one loop and places 
the string in namebuf. Earlier it was 3 passes over the string!

hash>bucket calculates the bucket to search from the hash and wid.
Wordlists can have different number of buckets

This saved 2-3 ms in recompiling the whole Forth system!
Hardly measurable but still a 5% improvement!

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

I checked the text and slides but did not like everything that was 
presented. I then downloaded a fresh tarball from gforth.org and
followed the instructions to install it on a debian WSL instance. 
It was not a good idea! running install-deps installed 150 packages
totaling 640 MB! Looked like mostly graphics stuff. I run only slim
console only installations of Linux!

I think it should have warned me before starting the installation!

Despite I saw install-deps compile swig with forth support configure 
did not find the freshly compiled copy and swig support was not avalible

The gforth binary runs just fine and I could confirm that the 
implementation was different and improved.

I think some instructions on how to compile without all this bloat
is needed. It looks mainly to be used for producing documentation 
in different formats.

BR
Peter
 
> @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

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