Names are resolved as follows:
a. There is a global symbol table for each locale. A global symbol table can be switched as an effect of 18!:4 or of executing a locative.
b. There is a local symbol table for each execution of an explicit definition.
c. A locative is sought in the current global symbol table and then in the search path (18!:2) for that table.
d. A non-locative is sought first in the local symbol table and then in the global symbol table.
e. Assignment to a non-locative using =. within an explicit definition is local. All other assignments are global. Global assignment to a local name is not permitted.
f. An undefined name is assumed to be a verb.
g. A name may not change its class (noun/verb/adverb/conjunction) within a context of 4 words, the magic number 4 being significant as the number of words in the execution context of the parser stack. Roughly speaking, changing the class of a name and then using that name all on the same line should be avoided.
The following examples were executed in a new session:
c ] ". 'c=:1' |domain error: c | c]".'c=:1'
The leftmost c is undefined and is treated as verb. Once the 4 words are on the parser stack ". is executed and c is assigned to be 1, a noun. A domain error is then signalled when c 1 is executed and c is found to have changed its class.
Compare with the following:
d=: +: d ] ". 'd=:1' |domain error: d | d]".'d=:1' e ] ] ". 'e=:1' 1
Commentary
You can use @SIG@ to sign your comments and questions.
If you think that there is some behavior that can not be explained by the rules as described, please say so here. -- RogerHui 2007-08-08 18:20:17
I thought there was a local symbol table for each instance an explicit definition was invoked. In other words, this is an error: (f=:3 :'if.y<2 do.t=.f y+1 else.t end.') 0 -- Raul Miller 2007-08-08 19:00:02
I have amended point b by adding "execution of an". -- RogerHui 2007-08-08 20:00:17
On e. it is possible to assign a global name when the name is also local by specifying the name as a locative. -- -- DonGuinn 2007-08-09 01:10:40
A locative can not be a local name. -- RogerHui 2007-08-09 16:38:49
Both remarks are useful from practical perspective. -- OlegKobchenko 2007-08-10 02:12:55
Non-local name for assignment is resolved as above, but if not found is created in the current locale. -- OlegKobchenko 2007-08-10 02:32:18
These points are covered by d and a. -- RogerHui 2007-08-10 16:06:44
Although it is possible to use locative to obviate the same local name, it is not always convenient or easy to know what is the current locale in a simple form, e.g. ('a_',(>coname''),'_')=. 1. However, there is the nice name__ default locative form, but it hardwired to base. But base is base, and if someone wants to specifically assign to base, can always use name_base_. Whereas the convenient and generic form name__ could be used to designate non-local name. In such role, it will overrule the local name preference even if local name exists. -- OlegKobchenko 2007-08-10 02:32:18
The essay describes the way the system is, not what it could be. -- RogerHui 2007-08-11 15:18:39
Any name is created only when assignment is executed, i.e. not when assignment is parsed, or just appears earlier from the right. See parsing and execution rules. Cf
a [ ".'a=.1' NB. ". not yet executed, a is undefined, thus treated as verb |domain error: a | a[0!:0'a=.1' a [ ] ".'a=.1' NB. parse rule complete, ". is executed, a is defined as noun 1
-- OlegKobchenko 2007-08-10 02:12:55
I have added point g. -- RogerHui 2007-08-11 15:18:39
the term "symbol table" from general parser theory sounds too technical, and overlaps with the meaning associated with the s: feature (and symbolic nature of APL/J primitives, i.e.!@#$%...). See J4C and LJ by searching J site. A possible alternative could be "name table". -- OlegKobchenko 2007-08-10 02:47:35