Named verbs are not replaced by their definitions except when they are
evaluated, thus:

   erase 'sum divide count'
1 1 1
   mean=: sum divide count
   mean 2 3 5
|value error: sum
|       mean 2 3 5

Here, we've defined something, but the definition is not complete:

   mean
sum divide count

But we can complete the definition:

   sum=: +/
   divide=: %
   count=: #

And, that let's us use it:

   mean 2 3 5
3.33333

This has some interesting consequences. One of them is that those
definitions have to be verb definitions:

   sum=: 10
   mean 2 3 5
|domain error: sum
|       mean 2 3 5
   mean
sum divide count
   mean=: sum divide count
   mean
10 divide count
  mean 2 3 5
3.33333

(One of the things I am illustrating here is that undefined names are
assumed to be verbs whose definitions will be provided later.)

But this does not get into what makes u special - for that you need it
to be an argument to an adverb (or a conjunction).

Here's how things work when we're not in an adverb or conjunction definition:

   u=: +/
   mean=:u divide count
   mean
u divide count

But here's how it works for an adverb:

   +/ 1 :'mean=:u divide count'
+/ divide count

But note that if the name being passed in from outside was u, that
this doubled use of u defeats that mechanism:

   u 1 :'mean=:u divide count'
u divide count

Is this starting to make sense?

Thanks,

-- 
Raul

On Mon, Nov 7, 2016 at 7:16 PM, Louis de Forcrand <[email protected]> wrote:
>    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
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to