[321] 2023-12-20 06:09:31 lmr wrote:

requestClarification - NAMETO, NAME

It might be useful to also have NAME<INTERPRET; but I suppose that use care is covered by DEFER and friends.

More interestingly, NAME<>TO would allow programming the behavior of TO explicitly, both for the user and when implementing the kernel.

[r1144] 2023-12-20 07:41:02 AntonErtl replies:

requestClarification - Negative n values

It's not specified, so systems can do whatever they want. Giving it some sane behaviour, as you suggest, appears to be a good idea.

Checking three systems, I see

• gforth 0.7.3 does not produce an error, but the resulting search order does not include order or set-order (and is probably corrupt, word completion produces an "invalid memory address" throw).

• SwiftForth 4.0.0-RC52 exits with a Segmentation fault.

• VFX Forth 64 5.11 RC2 appears to handle -2 set-order in the same way as -1 set-order.

[r1145] 2023-12-20 08:23:31 AntonErtl replies:

requestClarification - NAMETO, NAME

If you want to propose words that are not standardized, the way to do it is to write a proposal. But note that words for which there is little common practice are very unlikely to become standard eventually.

So the first thing you should do is to look at common practice. Gforth (development version) has words that work on the most recent definition:

• SET-EXECUTE ( ca -- ), but it takes a machine-code address and is unlikely to be standardizable.

• SET-DOES> ( xt -- ), which changes the most recent definition like DOES> does.

• DEFINER! ( definer xt -- ), but it is obsolete (will be removed in a future version of Gforth); it goes with >DEFINER ( xt -- definer ) for getting a definer.

• SET-TO ( xt -- ), but it takes the xt of a to-table that you have to define with TO-TABLE: (for also supporting +TO etc.). These words are still under discussion among Gforth developers.

You can make a definition "most recent" with MAKE-LATEST, but note that if you change a definition after it has already been used, the behaviour coming out of earlier uses may or may not change. For the thinking behind these words, you may want to read The new Gforth Header and/or watch the video.

VFX has a word for defining the interpretation semantics, but AFAIK not for TO.

For other Forth systems I am not aware that they have words for this kind of stuff, and it probably requires significant changes to add something like SET-TO (probably in VFX, too).

[r1146] 2023-12-20 10:34:25 lmr replies:

requestClarification - NAMETO, NAME

Thank you Anton. I've thought proposals, but as you said I'd need to check common practice, plus I want to make sure I'm not talking nonsense.

I've implemented this in my (Scheme-based) Forth, and it appears to ... just work. I kind of like it, as it allows the users to define TO-handlers in pure FORTH:

\ NAME>TO ( nt -- to-xt )  \ implementation-specific
\ NAME<TO ( to-xt nt -- )  \ implementation-specific, see do_to_value below for to-xt stack signature
: TO
  PARSE-NAME DUP 0= IF -16 THROW THEN
  FIND-NAME  DUP 0= IF -13 THROW THEN
  DUP NAME>TO  \ ( nt to-xt -- )
  STATE @ IF SWAP POSTPONE LITERAL COMPILE, ELSE EXECUTE THEN ;
IMMEDIATE

: do_to_value ( x nt -- ) NAME>INTERPRET >BODY ! ;
: VALUE >IN @ PARSE-NAME 2>R
              >IN ! CREATE , 
              ['] do_to_value 2R> FIND-NAME NAME<TO
              DOES> @ ;

(sorry for spamming an unrelated word... this should have been in the comment section for TO, but I don't know how to move it)