15.6.2.1909.20 NAME>INTERPRET name-to-interpret TOOLS EXT

( nt -- xt | 0 )

xt represents the interpretation semantics of the word nt. If nt has no interpretation semantics, NAME>INTERPRET returns 0.

Note:

This standard does not define the interpretation semantics of some words, but systems are allowed to do so.

See:

ContributeContributions

JennyBrienavatar of JennyBrien [88] How can the zero result be used in a Standard program?Request for clarification2019-07-02 10:29:22

AntonErtlavatar of AntonErtl

For a standard program, this is usually a restriction rather than an entitlement: It has to cope with the possibility of NAME>INTERPRET returning 0. Anyway, here is an example of how to deal with that: A user-defined text interpreter:

... parse-name 2dup find-name if nip nip
  state @ if
    name>compile
  else
    name>interpret dup 0= -14 and throw
  then
  execute
else
  ... deal with numbers
then

JennyBrienavatar of JennyBrien

My point is that this would only be useful in a system that has some way to explicitly mark definitions as having no interpretation semantics.

AntonErtlavatar of AntonErtl

The standard defines words with undefined interpretation semantics, and some systems implement this in some way; that's the reason for allowing NAME>INTERPRET to return 0. If you know your system never returns 0 from NAME>INTERPRET, you do not need to write the program in that way, but for portable programs, you have to take this possibility into account.

ruvavatar of ruv

I agree, the possibility of the zero result in name>interpret is only a restriction for programs (see also my rationale in comment #1111). But what does this possibility provide for systems? Nothing! Because in any case a system can have an internal word that returns xt|0 if it needs that.

It seems, a better choice was to make name>interpret always return some xt.

Reply New Version

ruvavatar of ruv [129] NAME>INTERPRET wordingProposal2020-02-20 09:55:14

This contribution has been moved to the proposal section.

ruvavatar of ruv

This reply has been moved to the proposal section.

AntonErtlavatar of AntonErtl

This reply has been moved to the proposal section.

ruvavatar of ruv

This reply has been moved to the proposal section.

ruvavatar of ruv

This reply has been moved to the proposal section.

ruvavatar of ruv

This reply has been moved to the proposal section.

ruvavatar of ruv

This reply has been moved to the proposal section.

ruvavatar of ruv

This reply has been moved to the proposal section.

ruvavatar of ruv

This reply has been moved to the proposal section.

ruvavatar of ruv

This reply has been moved to the proposal section.

ruvavatar of ruv

This reply has been moved to the proposal section.

ruvavatar of ruv

This reply has been moved to the proposal section.
Reply New Version

lmravatar of lmr [321] NAME<INTERPRET, NAME>TO, NAME<TORequest for clarification2023-12-20 06:09:31

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.

AntonErtlavatar of AntonErtl

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).

lmravatar of lmr

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)

Reply New Version