Just to clarify Henry's point.

> The value of (g =: ]) is (])

=: in J is "pass-through" , eg. when evalute a sentence

foo (f)=: g=: bar

what foo will see as its right argument is bar, not (f) or g.

Вс, 06 ноя 2016, Henry Rich написал(а):
> 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

-- 
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to