Can NAME>STRING be applied to a local variable?

[SirWumpus]

This is more a theoretical question (don't know why anyone would need to do these things in practice):

With all the recent discussion on comp.lang.forth thread "Back & Forth" - Local variables and a question on Forth Standard about NAME>STRING result is transient

• Can you obtain the nt of a local variable?
• Can you apply NAME>STRING to that local nt?
• What is the life time of the nt?

[CCurl]

It's simple ... DON'T USE LOCAL VARIABLES! Problem solved.

👍

[forthy42]

Simple answers:

• Yes, you can obtain the nt of a local variable by using words like FIND-NAME within the definition after the local was defined
• Yes, you can apply NAME>STRING
• Both have the same life time as the compilation process of the local variable, i.e. after the definition is finished, that memory is freed, and will be overwritten

[ruv]

• Yes, you can obtain the nt of a local variable by using words like FIND-NAME within the definition after the local was defined

I assume, the standard does not guarantee that.

FIND-NAME can find a local variable if and only if a special word list is added to the search order by the word «{:», or perhaps «:», «:NONAME», or «[:». I think, these words may do this, but they are not obligated to do so.

[ruv]

• Can you obtain the nt of a local variable?

There is no standard way to do it. But on some systems this is possible using FIND-NAME.

See also: Recognizer for locals.

• Can you apply NAME>STRING to that local nt?

Yes, sure. NAME>STRING applies to any nt.

• What is the life time of the nt?

I agree with Bernd, a program can expect a local variable's nt (if it is obtainable) to be valid only until compilation of the corresponding definition is finished.

[forthy42]

The standard says:

The system need not maintain these identifiers in the same way it does other dictionary entries as long as they can be found by normal dictionary searching processes. Furthermore, if the Search-Order word set is present, local identifiers shall always be searched before any of the word lists in any definable search order, and none of the Search-Order words shall change the locals' privileged position in the search order. Local identifiers may reside in mass storage.

I read ”found by the normal dictionary searching process” als FIND or FIND-NAME. When the recognizers are standardized, you can argue that “normal dictionary searching process” involves recognizers, and how to implement that without interference.

In a recognizer environment, the straight-forward implementation to that is to have search-order recognizer and a rec-locals recognizer, and you defer rec-nt to either be the search order recognizer sequence (locals inactive), or the combination of search-order and rec-locals sequence (locals active).

[ruv]

you defer rec-nt to either be the search order recognizer sequence (locals inactive), or the combination of search-order and rec-locals sequence (locals active).

I think, an implementation where a local variable identifier is not a subtype of nt is not prohibited. In such implementation, the recognizer:
rec-localvar ( addr u -- localvar-id localvar-translator | 0 )
cannot be part of the recognizer:
rec-nt ( addr u -- nt nt-translator | 0 ),
due to data types mismatch.

In compile time, a local variable is just a temporary association of a name with a number/offset (and maybe with the xt of a definition to which the variable belongs). A dynamic list or hash-table may suffice (instead of a normal word header and nt).