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


Groups > comp.lang.forth > #135184

Re: Naming issues in create-does

From Ruvim <ruvim.pinka@gmail.com>
Newsgroups comp.lang.forth
Subject Re: Naming issues in create-does
Date 2026-06-15 13:08 +0000
Organization A noiseless patient Spider
Message-ID <110oth6$capk$1@dont-email.me> (permalink)
References (7 earlier) <2026Jun12.202222@mips.complang.tuwien.ac.at> <6a2ccb22$1@news.ausics.net> <110itki$2o3o7$1@dont-email.me> <6a2d4b1f$1@news.ausics.net> <110jugl$31kdb$1@dont-email.me>

Show all headers | View raw


On 2026-06-13 15:55, Ruvim wrote:
> On 2026-06-13 12:20, dxf wrote:
>> On 13/06/2026 4:33 pm, Ruvim wrote:
>>> On 2026-06-13 03:14, dxf wrote:
[...]
>>>> DX-Forth implemented BUILD to support its compilation model.  I saw no
>>>> reason to persist with the 'CREATE then patch' concept.
>>>>
>>>>     : CONSTANT ['] @ BUILD , ;
[...]
>>>
>>> I would like to introduce a basic factor of your `BUILD` that accept 
>>> an xt and return other xt.
>>>
>>> How to call such a word?
>>>
>>> XXX ( xt1 -- xt2 )
>>> Create a nameless definition with the execution token xt2.
>>> If the data-space pointer is not aligned, reserve enough data space 
>>> to align it. The new data-space pointer defines the data field 
>>> associated with xt2. No data space is allocated in the data field. 
>>> The execution semantics identified by xt2 are as follows: Place the 
>>> data filed address associated with xt2 on the stack and execute xt1.

A possible name:

   BIND-DATAFIELD ( xt1 -- xt2 )
   \ A more narrow type specification:
   \ ( xt1[ any1 addr.data-field -- any2 ] -- xt2[ any1 -- any2 ] )

Rationale. In some popular languages, the verb "bind" is used in the 
name of a method/function that creates a partially applied function. In 
our case, we bind a function to a data filed, and also allow to use 
`>body` to obtain the data field address from the xt2. That is why the 
part "datafield" is present in the name.


>>
>> When you say it's a factor, do you mean xt1 is passed to BUILD in 
>> which case XXX is transparent?
>>
> 
> I mean that BUILD can be defined using XXX as follows:
> 
>     : BUILD ( xt1 "<spaces>name" -- )
>       XXX ( xt2 ) PARSE-NAME ENLIST
>     ;

A problem with this approach is that `enlist` reserves (allocates) a 
data space range withing the data field associated with xt2.

Thus, neither `create` nor `build` can be defined using such XXX.

Some other words can. For example:

   : alias ( xt "<space>name" -- ) parse-name enlist ;

   : constant ( x "<spaces>name" -- )
     ['] @ bind-datafiled >r  ,  r> alias
   ;




> 
> Where the word ENLIST places a new word to the compilation word list.
> 
> ENLIST ( xt1 sd.name -- )
> Place a named definition into the compilation word list; the
> definition's name matches the character string sd.name, and the
> definition's execution semantics are equivalent to the execution
> semantics identified by xt1.
> 
> 
> One of the issues I currently see is that, for `>body` to work
> correctly, `enlist` must guarantee either the identity of the execution
> token:
> 
>    t{ :noname ;  dup s" foo" enlist -> ' foo }t
> 
> or, at least, the identity of the data field (and other associated
> properties):
> 
>    t{ create bar  ' bar >body  ' bar s" foo" enlist -> ' foo >body }t
> 

--
Ruvim

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


Thread

Back to the Forth Virus clv2020 <clv2020@vodafonemail.de> - 2026-06-08 13:40 +0200
  Re: Back to the Forth Virus Jan Coombs <jan4etsept@murray-microft.co.uk> - 2026-06-08 13:16 +0100
  Re: Back to the Forth Virus Ruvim <ruvim.pinka@gmail.com> - 2026-06-08 12:23 +0000
    Re: Back to the Forth Virus Daniel Cerqueira <dan.list@lispclub.com> - 2026-06-08 13:56 +0100
      Re: Back to the Forth Virus anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-08 15:40 +0000
        Re: Back to the Forth Virus Daniel Cerqueira <dan.list@lispclub.com> - 2026-06-08 19:26 +0100
          Re: Back to the Forth Virus anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-08 20:06 +0000
        GForth reproducible builds (was Re: Back to the Forth Virus) Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-02 14:40 -0300
  Re: Back to the Forth Virus minforth <minforth@gmx.net> - 2026-06-09 01:01 +0200
    Re: Back to the Forth Virus clv2020 <clv2020@vodafonemail.de> - 2026-06-10 13:13 +0200
      Re: Back to the Forth Virus minforth <minforth@gmx.net> - 2026-06-11 10:01 +0200
        Re: Back to the Forth Virus anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-11 17:28 +0000
          Naming issues in create-does (was: Back to the Forth Virus) Ruvim <ruvim.pinka@gmail.com> - 2026-06-12 17:23 +0000
            Re: Naming issues in create-does (was: Back to the Forth Virus) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-12 17:52 +0000
              Re: Naming issues in create-does (was: Back to the Forth Virus) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-12 18:22 +0000
                Re: Naming issues in create-does dxf <dxforth@gmail.com> - 2026-06-13 13:14 +1000
                Re: Naming issues in create-does Ruvim <ruvim.pinka@gmail.com> - 2026-06-13 06:33 +0000
                Re: Naming issues in create-does dxf <dxforth@gmail.com> - 2026-06-13 22:20 +1000
                Re: Naming issues in create-does Ruvim <ruvim.pinka@gmail.com> - 2026-06-13 15:55 +0000
                Re: Naming issues in create-does Ruvim <ruvim.pinka@gmail.com> - 2026-06-15 13:08 +0000
                Re: Naming issues in create-does Hans Bezemer <the.beez.speaks@gmail.com> - 2026-07-23 19:58 +0200
                Defining words in more than one step (was: Naming issues in create-does) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-13 06:46 +0000
                Re: Defining words in more than one step dxf <dxforth@gmail.com> - 2026-06-14 12:29 +1000
              Re: Naming issues in create-does Ruvim <ruvim.pinka@gmail.com> - 2026-06-12 19:59 +0000
                Re: Naming issues in create-does anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-13 10:25 +0000
                Re: Naming issues in create-does Ruvim <ruvim.pinka@gmail.com> - 2026-06-13 15:30 +0000
                Re: Naming issues in create-does anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-06-13 17:30 +0000
              Re: Naming issues in create-does (was: Back to the Forth Virus) peter <peter.noreply@tin.it> - 2026-06-13 20:21 +0200
  Re: Back to the Forth Virus dxf <dxforth@gmail.com> - 2026-06-09 12:14 +1000
    Re: Back to the Forth Virus "Kerr-Mudd, John" <admin@127.0.0.1> - 2026-06-10 18:54 +0100
      Re: Back to the Forth Virus dxf <dxforth@gmail.com> - 2026-06-11 16:32 +1000
        Re: Back to the Forth Virus "Kerr-Mudd, John" <admin@127.0.0.1> - 2026-06-11 14:20 +0100
  Re: Back to the Forth Virus Stephen Pelc <stephen@vfxforth.com> - 2026-06-09 10:22 +0000
    Re: Back to the Forth Virus clv2020 <clv2020@vodafonemail.de> - 2026-06-10 15:55 +0200
  Re: Back to the Forth Virus albert@SPENARNC.XS4ALL.NL - 2026-07-24 13:35 +0200

csiph-web