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

Reply via email to