Names are resolved as follows:
b. There is a local symbol table for each execution of an explicit definition.
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
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. -- Roger Hui <<DateTime(2007-08-08T18:20:17Z)>>
- 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 <<DateTime(2007-08-08T19:00:02Z)>>
- I have amended point b by adding "execution of an". -- Roger Hui <<DateTime(2007-08-08T20:00:17Z)>>
- On e. it is possible to assign a global name when the name is also local by specifying the name as a locative. -- -- Don Guinn <<DateTime(2007-08-09T01:10:40Z)>>
- Non-local name for assignment is resolved as above, but if not found is created in the current locale. -- Oleg Kobchenko <<DateTime(2007-08-10T02:32:18Z)>>
- These points are covered by d and a. -- Roger Hui <<DateTime(2007-08-10T16:06:44Z)>>
- 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. -- Oleg Kobchenko <<DateTime(2007-08-10T02:32:18Z)>>
- The essay describes the way the system is, not what it could be. -- Roger Hui <<DateTime(2007-08-11T15:18:39Z)>>
- 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
-- Oleg Kobchenko <<DateTime(2007-08-10T02:12:55Z)>>
- I have added point g. -- Roger Hui <<DateTime(2007-08-11T15:18:39Z)>>
- 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". -- Oleg Kobchenko <<DateTime(2007-08-10T02:47:35Z)>>