This is not a bug and the explanation is in my long message.  Briefly,
c_my1_ executes in my1, but the derived verb (>: c_myl_ +) executes in the user's locale.

Note that c references a when the derived verb is executed, but cp references a when cp itself is executed. This really points out the differences in the two executions.

Henry Rich


On 11/17/2013 10:53 AM, Pascal Jasmin 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

Reply via email to