15.6.2.1909.40 NAME>STRING name-to-string TOOLS EXT
NAME>STRING returns the name of the word nt in the character string c-addr u. The case of the characters in the string is implementation-dependent. The buffer containing c-addr u may be transient and valid until the next invocation of NAME>STRING. A program shall not write into the buffer containing the resulting string.
See:
ContributeContributions
ruv
[374] `NAME>STRING` result is transientRequest for clarification2025-01-22 16:50:21
15.6.2.1909.40 NAME>STRING says:
The buffer containing c-addr u may be transient and valid until the next invocation of
NAME>STRING.
What is the point of allowing the returned string to be in a transient buffer? Which implementation approach benefits from that?
In typical implementations, the lifetime of the returned string is the same as the lifetime of nt.
AntonErtl
I think the idea was to allow systems that store definition names in a representation other than that returned by NAME>STRING. One example would be the fig-Forth representation of names, which sets the high bit of the last byte (fig-Forth only supports names in ASCII).
Now that we have had NAME>STRING in the standard for a decade, we can look at the systems that actually implement this word. If they all return a name that lives as long as the definition, we could enhance this word by giving that guarantee. But who will examine the systems and make the proposal?
ruv
I have checked. There are about 22 Forth systems on GitHub that provide name>string implemented in Forth (see the search results).
Among these systems there is only one system, namely solo-forth (description: "Standard Forth system for ZX Spectrum 128 and compatible computers, with disk drives"), in which the word name>string returns a string in a transit buffer. This system has to copy the resulting string into the transient buffer because the header space and the data space are located in different address spaces.
ruv
So, the only advantage of a transient result is that it allows to save memory in some cases. And it only makes sense when saving 10-100 KiB of memory (say, 8% of compiled code size) matters.
An example of approach that can benefit is the use of a trie data structure (prefix tree) to implement efficient searching of word lists. This data structure does not need to store entire strings. Therefore, to save memory, a transient string for a word name can be constructed each time it is needed.
EkkehardSkirl
[423] The buffer containing c-addr u may be transient and valid until the next invocation of NAME>STRINGRequest for clarification2026-02-09 11:33:18
(1) Being transient until the next call to 'NAME>STRING' necessitates that this word requires its own transient space and cannot use the transient spaces of other words or a central transient space while, for example, a word search is running " (see also (3)(a)). So more precise may be "... and is valid ...".
(2) Not being transient leads to duplicate longtime storage of the same information in cases where the name is stored in a system-specific way other than returned.
(3) What is the purpose of this word? To retrieve the name of a compiled word. But for what purpose? Since the name of a word only plays a role in interpretation and is then only implicitly stored as 'xt', I currently find only two reasons:
(3a) Word searches during interpretation or compilation, especially in systems that use a different form of name storage.
(3b) Debugging or recompiling a word.
However, neither of these necessitates storing the name string non-transiently as long as NAME>STRING uses its own transient area.
(4) The standard does not impose a transient storage area on any system, because it states "The buffer containing c-addr u may be ...".
ruv
Being transient until the next call to
NAME>STRINGnecessitates that this word requires its own transient space and cannot use the transient spaces of other words
Yes, but a transient buffer is not required, it is only allowed.
So more precise may be "... and is valid ...".
Or maybe this:
"The buffer containing c-addr u may be transient, but in any case it must be valid until the next invocation of NAME>STRING"