A word that creates a name token for xt

[ruv]

There is a well known word alias ( xt "name.new" -- ) that creates a Forth word with the specified name and xt. This word accepts the name from the input buffer. I need a factor for this word that accept all arguments from the stack. Also, I need a factor for the standard word synonym ( "name.new" "name.old" -- ).

How to name these factors? Which order of arguments is better?

I think about:

• build-name ( xt sd.name -- )
• build-synonym ( nt sd.name -- )

The created name token can be obtained by latest-name.

So these words can be used as:

: alias ( xt "name.new" -- ) parse-name  build-name ;
: synonym ( "name.new" "name.old" -- ) parse-name 2>r  parse-name find-name ?found 2r> build-synonym ;

[tuffnatty]

GForth offers a composable alternative: nextname

[ruv]

Thanks, but the Gforth's word nextname is not suitable.

I'm just looking for better names than "build-name" and "build-synonym". Perhaps some Forth systems already provide such words.

[alextangent]

: alias ( xt -<name>- ) header xtc! ; \ make another 'name' for 'xt'

: synonym ( -<newname> <oldname>- )
    header hide
    definite-find
    name>xtimm 1 = if immediate then         \ make synonym immediate
    xtc! reveal ;                \ set the xt pointer of header

XTC! requires (in my system) carnal knowledge. Note the use of HIDE and REVEAL in SYNONYM; since we may want to define the new name the same as an existing name, but not in the same dictionary.

[alextangent]

Apologies, hit enter too quickly. As you can see from the example, the factored word is HEADER.

: header ( -<name>- )          \ build a header
    align                      \ align data space
    parse-name dup 0= throw_namereqd ?throw
    get-current voc.head perform ; \ perform the word at voc.head

Wordlists (a subset of a named vocabulary) in my system are objects that have three methods; to create entries, find entries, and display entries. This allows dictionaries to be flexible as to, for instance, the case of the name. Windows functions are case sensitive, so the dictionaries for them use case sensitive create and find; whereas standard Forth dictionaries are case insensitive. So (not a particularly useful example)

also imports           \ the Windows call dictionary
synonym beep Beep      \ define a Forth word called BEEP from the Windows word Beep
previous

Hence the advice about HIDE REVEAL.

HEADER is a pretty obvious word for defining a header in a dictionary (IMHO, usual caveats), and I haven't seen it used elsewhere.

[ruv]

@alextangent wrote:

: alias ( xt -<name>- ) header xtc! ; \ make another 'name' for 'xt'

: synonym ( -<newname> <oldname>- )
    header hide
    definite-find
    name>xtimm 1 = if immediate then         \ make synonym immediate
    xtc! reveal ;                \ set the xt pointer of header

So, in your system build-name and build-synonym can be implemented as follows:

: build-name ( xt sd.name -- )
  ['] header execute-parsing xtc!  ;

: build-synonym ( nt sd.name -- )
  ['] header execute-parsing
  ( nt ) name>xtimm 1 = if immediate then
  ( xt ) xtc!  ;

Do you like the names "build-name" (i.e., to build a name token for given xt) and "build-synonym"?

[alextangent]

@alextangent wrote:

So, in your system build-name and build-synonym can be implemented as follows:

: build-name ( xt sd.name -- )
  ['] header execute-parsing xtc!  ;

I have (header) ( a1 n1 -- ) where I use ( ) to indicate an internal word and very probably a word that requires carnal knowledge; that is, not there for general use.

[SirWumpus]

For the alias case maybe two parts:

• created ( sd.name -- nt ) \ default xt is a NOP
• set-xt ( xt nt -- )

What xt does alias assign? Compile or interpret behaviour or both?

: alias ( xt <spaces>name -- ) created set-xt ;
: synonym ( <spaces>new <spaces>old -- ) parse-name created ' swap set-xt ;

[ruv]

• set-xt ( xt nt -- )

In some standard Forth systems it is not possible to associate an arbitrary xt with an nt (for example, when xt = nt, that is xt ⇒ nt and nt ⇒ xt ).

An important property of the word build-name is that it must satisfy the following test:

t{ :noname ; dup s" foo" build-name latest-name name>interpret = -> true }t

---

: synonym ( <spaces>new <spaces>old -- ) parse-name created ' swap set-xt ;

This cannot work in dual-xt systems.

A factor of synonym shall allow to define synonym in a standard program.

[SirWumpus]

In some standard Forth systems it is not possible to associate an arbitrary xt with an nt (for example, when xt = nt, that is xt ⇒ nt and nt ⇒ xt ).

Yep. But "under the hood" set-xt could set the necessary fields (code field, bits like immediate, compile-only, etc.) from to the old xt into the new nt.

[SirWumpus]

Are you trying to factor alias and synonym, which are probably already kernel built-ins with intimate implementation knowledge, into smaller and smaller pieces much like splitting an atom into quantum particles and sub-particles?

[ruv]

But "under the hood" set-xt could set the necessary fields (code field, bits like immediate, compile-only, etc.) from to the old xt into the new nt.

In some systems it is possible, in other — it is not possible; for example, even if the new word has the same behavior, its execution token will be different.

Are you trying to factor alias and synonym, which are probably already kernel built-ins with intimate implementation knowledge, into smaller and smaller pieces much like splitting an atom into quantum particles and sub-particles?

😄 No. At least, too small factors are impossible to implement equally in all Forth systems. I need the factors that simply accepts parameters from the data stack and do not resolve names by themself.

1. The factor for synonym (that I ask) is implementable in any Forth system that provides synonym.
   • This factor is required to implement the Recognizer API Ext.
2. The factor for alias is also implementable in any Forth system that provides alias.

Actually, I ask only for better names (if any), because I will implement these words anyway.

[ruv]

I think about:

• build-name ( xt sd.name -- )
• build-synonym ( nt sd.name -- )

The word "build" is not very suitable. In computing, it has a strong connotation of compilation from sources (as a verb) and a connotation of versioning (as a noun).

Which of the following options do you like more?

• Using the verb "to define":
  • define-name ( xt sd.name -- )
  • define-synonym ( nt sd.name -- )
• Using verb "to register":
  • register-name ( xt sd.name -- )
  • register-synonym ( nt sd.name -- )
• Using verb "to enroll":
  • enroll-name ( xt sd.name -- )
  • enroll-synonym ( nt sd.name -- )

[SirWumpus]

• compose-name
• compose-synonym

?

[ruv]

I like the options "register" and "enroll" because they imply a place where an entity will be registered or enrolled — in our case it is the compilation word list. The word "define" is also associated with vocabularies or word lists. But the word "compose" does not have such meaning. It seems, compose-synonym should return an entity that it creates.

For example, a composition of two functions: compose ( xt1 xt2 -- xt3 ) returns an explicit result.

[ruv]

Probably, "to enlist" is better than "to enroll":

• enlist-name ( xt sd.name -- )
  • some other options for this word:
    • enlist-word ( xt sd.name -- )
    • enlist-definition ( xt sd.name -- )
    • enlist ( xt sd.name -- )
• enlist-synonym ( nt sd.name -- )

Etymology: to enlist an entity — to add the entity into the compilation word list.

[SirWumpus]

• capture-and-beat-into-submission-name ( xt sd.name -- )
• I-want-it-my-way-synonym ( nt sd.name -- )

Too long?

[ruv]

Too long?

Sure! 😄

[ruv]

that creates a Forth word with the specified name and xt.

In some Forth systems it's impossible to define a word enlist-definition ( xt sd.name -- ) that satisfies the following test:

: foo 123 ;
t{ ' foo s" bar" enlist-definition -> }t
t{ ' bar ' foo = -> true }t

Because this test requires that the Forth system be able to associate the same xt with several Forth words (name tokens), but in some systems this is impossible due to their internal design.

Well, technically you can add such association anyway by redefining ', ['], name>interpret, find, search-wordlist so they remap a new xt to the old xt. But this is inefficient.

On the other hand, if the Forth system provides synonym, it is probably able to associate the same xt with several Forth words. Otherwise, it has to be able to associate the same data field address with multiple execution tokens to satisfy the following test:

create foo 123 ,
synonym bar foo
t{ ' bar >body  ' foo >body  = -> true }t