v=: 3 : 0 u=. 10 f y ) f=: 3 : 'u' u=: 5 f '' 5 v '' 5 Here I used u, but it still works as expected.
v=: 3 : 0 g=. +: f y ) f=: g g=: ] f 5 5 v 5 10 The "strange" behaviour does not seem to depend on the names used here; it depends on wether the name which is shadowed is a verb or not, as far as I can tell. Louis > On 08 Nov 2016, at 01:01, Raul Miller <[email protected]> wrote: > > Because the name 'u' is a special name. One of six special names in > the language. > > -- > Raul > > >> On Mon, Nov 7, 2016 at 6:37 PM, Louis de Forcrand <[email protected]> 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: >> >> 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? >> >> Thanks, >> Louis >> >>> On 07 Nov 2016, at 03:40, Henry Rich <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
