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
