Thank you. I got the verb versus pro-verb problem; I guess it can be surprising to newcomers, but it is logical.
However, I don't understand why sending a verb such as f=: g to an adverb which (locally) redefines g allows f to see the local definition of g, whereas sending a verb such as h=: 3 : 'd' to an adverb which redefines d does not allow h to see the local definition of d. Is it because h is run in its own locale, while f is not? Would that mean that f=: 3 : 'g y' would not be able to see local g, while f=: g would?
Keep in mind that, although I did complete the locales lab a littlie while ago, I program as a hobby and thus have little to no experience whatsoever with OOP and locales.
Louis
> On 07 Nov 2016, at 03:17, Henry Rich <henryhrich at gmail.com> wrote:
>
> I didn't read all this, but I sympathize with your perplexity. If you give an individual testcase that produces a result you don't expect, and give a thorough justification of why you expect something different, veterans here will explain what's happening. More probably, you will discover the reason yourself as you try to create the justification.
>
> Just to pick up on one thing I did see: The value of (g =: ]) is (]), a primitive with no name, which is not the same as (g), a name.
>
> Henry Rich
>
>> On 11/5/2016 12:38 PM, Louis de Forcrand wrote:
>> I must say this is very confusing.
>> Shouldn’t any function that
>> a) makes no use of any foreigns or ?,
>> b) uses only local definition =. and
>> c) does not access any global variables (or has shadowed them with a local definition)
>> return the same result every time it is run with identical (same value) arguments?
>>
>> a=: 1 : 0
>> g=. +:
>> u y
>> )
>>
>> ] a 5
>> 5
>> (u=: ]) a 5
>> 5
>> (g=: ]) a 5
>> 5
>> g a 5
>> 10
>> u a 5
>> |stack error: u
>> | u y
>>
>> That is _very_ misleading. I understand that in the first 3 cases ] is passed by value
>> and in the other two by name, but I still see this as strange behaviour. When the adverb’s
>> argument is u, wether u has a value or not in the calling locale, gives a stack error. Using g,
>> no matter the value of g, gives 10. Using any other undefined name gives a value error.
>> Finally, using an anonymous function or proverb which isn’t g or u yields the correct answer.
>> That’s 3 different results or errors for basically one input _value_ (not counting the correct
>> value error).
>> The worst one IMHO is (g=: ]) a 5 versus g a 5. Finding such an error must be a quite
>> painful experience. Note that this happens here as well:
>>
>> a=: 1 : 0
>> u=. +:
>> g y
>> )
>>
>> g=: u=: ]
>> g a 5
>> 5
>> u a 5
>> 5
>> g=: u
>> u=: ]
>> g a 5
>> 10
>> u a 5
>> 10
>>
>> I guess this means that function arguments can access variables which are local to the
>> calling adverb. So can functions that use a value referred to by a global variable see
>> this value change if they are supplied as an argument to an adverb? Apparently not:
>>
>> g=: 3 : 'global'
>> global=: 5
>> a=: 1 : 0
>> global=. 10
>> u y
>> )
>> g 0
>> 5
>> g a 0
>> 5
>>
>> This is how I would have expected it to work in the first place. Why then can a function
>> argument to an adverb (unexpectedly) access a verb which is local to the adverb,
>> while it (as expected) cannot access a local variable?
>>
>> Louis
>>
>>> On 05 Nov 2016, at 15:33, Raul Miller <rauldmiller at gmail.com> wrote:
>>>
>>> On Sat, Nov 5, 2016 at 10:09 AM (EST), I wrote:
>>>> ... Now that I think this through, I think I can do a passable job of that.)
>>> Actually, no, I do not.
>>>
>>> Extracting the locale from a name is straightforward:
>>>
>>> conamed=:3 :0
>>> 'a b'=. _2{.I.'_'='_',y
>>> if. (0=a)+.1~:#;:y do. NB. implied
>>> 18!:5 ''
>>> elseif. b=a+1 do. NB. indirect
>>> ".b}.y
>>> elseif. do. NB. direct
>>> <}:a}.y
>>> end.
>>> )
>>>
>>> And, getting the name of an adverb argument is trivial:
>>>
>>> ;u`''
>>>
>>> However, this does not address the issue faced by jtrace, which is
>>> finding the locale that jtrace was invoked from.
>>>
>>> As a workaround, I would recommend assuming that that locale was the
>>> base locale. This potentially reduces the utility of the jtrace
>>> facility, but it seems like the right balance of simplicity.
>>> Specifically, I am recommending changing line 8 of executet_jtrace_
>>> and executep_jtrace_ from
>>>
>>> ". 't_z=. ', ; t_x
>>> and
>>> ". 't_z=. ',t_x=. '(',(;:^:_1 t_x),')'
>>>
>>> to
>>>
>>> do_base_ 't_z=. ', ; t_x
>>> and
>>> do_base_ 't_z=. ',t_x=. '(',(;:^:_1 t_x),')'
>>>
>>> Does this make sense?
>>>
>>> Thanks,
>>>
>>> --
>>> Raul
>>> ----------------------------------------------------------------------
>>> 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