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
