good idea,
small correction, you mean create method instead of conew.
If it is a multiline definition, we need to use the same ; trick I did for:
2 : (':';'u a__x v y')
----- Original Message -----
From: Raul Miller <[email protected]>
To: Programming forum <[email protected]>
Cc:
Sent: Sunday, November 17, 2013 2:18:17 PM
Subject: Re: [Jprogramming] bug in conjunction locales?
In other words, for this example:
w =: conew 'myl'
a__w =: 4
c__w =: 2 : 'u a v y'
c2__w =: 2 : 'u@:(a&v)'
put the definition of c__w and c2__w inside conew, and instead of
simply referring to a, refer to a_',(>w),'_
(Note that I have assumed an explicit quoted context here.)
Thanks,
--
Raul
On Sun, Nov 17, 2013 at 2:13 PM, Pascal Jasmin <[email protected]> wrote:
>> And you can, of course, have conew create a new instance of theconjunction
>> in the numbered locale.
>
> I likely don't understand what you are suggesting here.
>
> is it:
>
> w =: conew 'myl'
> a__w =: 4
> c__w =: 2 : 'u a v y'
> c2__w =: 2 : 'u@:(a&v)'
>
> That doesn't address the bug, because c__w only sees 'a' in caller even
> though c2__w correctly sees a__w.
>
> the best workaround IMO is to let the caller pass the locale:
>
> c_z_ =: 2 : (':';'u a__x v y')
>
> and then called as:
>
> w >: c + 1
> or
> (<'myl') >: c + 1
>
>
> The downside is that you get an extra function in z that only works with a
> narrow set of locales, and more resulting explicit documentation requirements.
>
> A point I should have made in my reply to Henry, is that the interpreter is
> already behaving "correctly" some of the time (tacit result modifiers), and
> so hopefully working correctly all of the time shouldn't seem like an
> unreasonable request, or (uninformed assumption) require new code path
> development.
>
>
>
>
> ----- Original Message -----
> From: Raul Miller <[email protected]>
> To: Programming forum <[email protected]>
> Cc:
> Sent: Sunday, November 17, 2013 1:33:51 PM
> Subject: Re: [Jprogramming] bug in conjunction locales?
>
> On Sun, Nov 17, 2013 at 12:12 PM, Pascal Jasmin <[email protected]>
> wrote:
>>> And it's rather trivial for a conjunction
>> to access the state of its native locale (just be explicit about
>> that).
>>
>> It's trivial for static locale, but fails for numbered locales derived with
>> conew, because the code will never have access to the number unless
>> the caller passes it. -- which is the workaround I've used.
>
> That's one fairly easy mechanism. Another mechanism involves conew.
>
>
>> In terms of OOP (numbered locale) use, its not fair to say it should
>> be avoided for J. If a table, file, database, socket connection are
>> usefully encapsulated in a locale, then the concept that you might
>> want to have more than one of these in your program makes numbered
>> locales relevant.
>
> And yet, t should be avoided sometimes and not other times.
>
> Another issue with J's locales is: if they are misused you run into
> resource issues. Just like any other computational mechanism, sometimes
> resources matter.
>
> And you can, of course, have conew create a new instance of the
> conjunction in the numbered locale. The cost should be trivial
> (unless you are misusing the concept).
>
> Remember that conew knows about the new locale and runs before anything
> else in that locale.
>
> 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
