In J (and APL) the ideal is for relevant state to be present in the arguments.
The locales were designed as a way of encapsulating design so that what one person builds can be used by another person without having to worry too much about naming. And it's rather trivial for a conjunction to access the state of its native locale (just be explicit about that). I'm not saying you are not right, of course. I simply have not spent enough time studying the dictionary nor past discussions on this topic to say for sure. But I wanted to offer some additional perspective. Thanks, -- Raul On Sun, Nov 17, 2013 at 10:53 AM, Pascal Jasmin <[email protected]> wrote: > I added a bug report and narrowed down the issue: > > Most likely the error occurs when a modifier definition accesses y. This > cannot be intentional design because one locale's definition cannot possibly > rely on another locale's state, and the primary reason for defining a > modifier in a specific locale is to use that locale's environment. > > > cocurrent 'myl' > a=: 4 > c =: 2 : 0 NB. will execute wrong (callers) locale > smoutput 18!:5 '' > u a v y > ) > cp =: 2 : 0 NB. will execute right (this) locale > smoutput 18!:5 '' > v@:u^:a > ) > > cocurrent 'newl' > > c2_myl_ =: 2 : 0 > smoutput 18!:5 '' > u a v y > ) > > test =: 3 : 0 > a=: 14 > smoutput >: c_myl_ + 1 > smoutput >: c2_myl_ + 1 > c =: conew 'myl' >>: c2__c + 1 > ) > > in session: > > test_newl_ '' NB. results should be 6 (and <'myl') for all 3. > ┌────┐ > │newl│ > └────┘ > 16 > ┌────┐ > │newl│ > └────┘ > 16 > ┌────┐ > │newl│ > └────┘ > 16 > > conjunction that does not access y in session (or script): > conj_myl_=: 2 :'v@:u^:a' > >: conj_myl_ ] 1 NB. result for both should be 5 > 5 > >: cp_myl_ ] 1 > 5 > > c3_myl_ =: 2 : 'u@:(a&v)' > >: c3_myl_ + 1 NB. result should be 6 > 6 > > > > ----- Original Message ----- > From: Henry Rich <[email protected]> > To: [email protected] > Cc: > Sent: Sunday, November 17, 2013 12:14:24 AM > Subject: Re: [Jprogramming] bug in conjunction locales? > > I cannot replicate this (I run J602). > > conj_cat_=: 2 :'v@:u^:a' > a_cat_ =: 5 > + conj_cat_ - > -@:+^:5 > > load 'C:\Jprograms\temp\99.ijs' > NB. contents of the script are: > NB. conj_dog_=: 2 :'v@:u^:a' > > a_dog_ =: 6 > + conj_dog_ - > -@:+^:6 > > Henry Rich > > On 11/16/2013 11:36 PM, Pascal Jasmin wrote: >> I'll just make this shorter. The only bug is in script files vs. >> interactive mode. The key to (and only way of) noticing the bug is to use a >> conjunction definition that accesses an external parameter affected by what >> the current locale is (such as the 'a' parameter in following): >> >> conj_cat_=: 2 :'v@:u^:a' >> >> >> If the above is defined in repl then it will correctly use a_cat_, and use a >> late binding for a. >> >> If it is defined in a script file, then a will be whatever 'a' is in the >> caller's locale. >> >> I of course agree with you in what the locale of verb vb should be, but that >> is unrelated to this issue. I agree with the interactive mode's execution >> of locales. But at any rate, either interactive or script mode necessarily >> has a bug. >> >> >> ----- Original Message ----- >> From: Henry Rich <[email protected]> >> To: [email protected] >> Cc: >> Sent: Saturday, November 16, 2013 11:02:10 PM >> Subject: Re: [Jprogramming] bug in conjunction locales? >> >> The point, as Raul has pointed out, is that 'execution' of the >> conjunction is not what you think it is. Raul said that conjunctions >> are executed twice, which is not quite right: the conjunction is >> executed once, to produce an anonymous verb, and then that verb is >> executed, at which time the text of the conjunction is interpreted. >> >> Consider >> >> vb =: + c_loc_ - >> >> Assume c_loc_ is defined like >> c_loc_ =: 2 : 0 >> u@v y >> ) >> >> What is vb? >> >> Answer: it is the result of executing c_loc_ . It is a verb, which >> contains the +, -, and text of c_loc_, saved for interpretation when vb >> is executed. The text of c_loc_ has not been executed. >> >> What is the locale of vb? >> >> Answer: whatever locale was in effect when it was defined. The loc >> locale has nothing to do with vb. >> >> Why doesn't >> vb 3 >> execute in loc? >> >> Answer: Why should it? c_loc_ has been executed and is a distant >> memory. vb contains the text that was in c_loc_, but it is not c_loc_, >> and is not in the loc locale. >> >> What about >> (+ c_loc_ -) 3 >> ? What locale does it execute in? >> >> Answer: The locale that was in effect. Now there is no name vb, but >> the idea is the same: the verb (+ c_loc_ -) is an /anonymous verb/ >> and it is defined in the locale in effect. It executes in that locale. >> >> Given >> vb_loc1_ =: + c_loc_ - >> vb_z_ =: vb_loc1_ >> vb 3 >> what locale is in effect when the text of vb is executed? >> >> Answer: loc1. Again, c_loc_ is long gone, and executing vb_loc1_ >> sets the locale to loc1. >> >> Isn't this a bug? >> >> Answer: No. To say otherwise would be to say that a derived verb >> must inherit locale from its components. Then there is a whole new set >> of problems: >> vb =: (+ adv_loc1) @ (- adv_loc2) >> What would be the locale of vb? >> vb =: (+ adv_loc1) (- adv_loc2) (- adv_loc3) >> What would be the locale of vb? >> >> The current definition is clear and crisp, and hasn't revealed any >> insuperable problems. >> >> JfC discusses this in more detail. >> >> Henry Rich >> >> >> On 11/16/2013 10:39 PM, Raul Miller wrote: >>> The issue, I think, is that (except for verbs) names are resolved to >>> their definitions before their definitions are used. >>> >>> require 'trace' >>> trace 'verb_dog_ conj_cat_ %' >>> --------------- 4 Conj ------- >>> verb_dog_ >>> 2 : 'u&.(v inv)' >>> % >>> verb_dog_&.(%^:_1) >>> ============================== >>> >>> Notice how the verb is named and the conjunction is not. >>> >>> I remember there being an explanation for this but I do not remember >>> if that was grounded in "efficiency concerns" or in dictionary. >>> >>> Thanks, >>> >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm >> >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm > >> > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
