[Jprogramming] stack error or private/public name collision
Henry Rich
henryhrich at gmail.com
Tue Nov 8 00:01:10 UTC 2016
First off: I have added some words to the Wiki about this. Look at
http://code.jsoftware.com/wiki/Vocabulary/com#What_Are_Those_Names_Set_To.3F
Comments below
On 11/7/2016 6:37 PM, Louis de Forcrand wrote:
> Henry, this puzzles me:
>
> v=: 3 : 0
> u=. +:
> f y
> )
> f=: u
> u=: ]
> v 5
> 10
>
> Here, f uses the local value of u. This surprised me. However:
The value of (f) is the name (u). When f is executed, the name (u) is
looked up, and the first place searched is the local name table.
>
> v=: 3 : 0
> g=. 10
> f y
> )
> f=: 3 : 'g'
> g=: 5
> v ''
> 5
>
> Here, f uses the global value of g (as I expected).
>
> Why is this so?
When (f) starts, it is given its own namespace. It searches for (g) in
that namespace. This search fails. The search continues in the current
locale, which finds the public name (g). [If the name had not been
defined there, the search would have continued using the search path of
the current locale.]
The namespace of (v) is private to (v) and is not visible from any other
definition, even one called from (v).
Henry Rich
>
> Thanks,
> Louis
>
>> On 07 Nov 2016, at 03:40, Henry Rich <henryhrich at gmail.com> wrote:
>>
>> Sorry to throw the burden back on you, but please give an example showing what you think is wrong or puzzling; what you think it should be; and why you think that. English is simply inadequate to frame such questions with the requisite precision.
>>
>> From what I have seen, lack of experience with other languages is a benefit for learning J.
>>
>> Henry Rich
>>
>>
>> On 11/6/2016 9:35 PM, Louis de Forcrand wrote:
>>> 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
>>> ----------------------------------------------------------------------
>>> 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
More information about the Programming
mailing list