This domain error is a feature, it was introduced some years (or a decade?) 
ago. I found it helpful. ymmv.

On 20.06.2014, at 19:45, "'Pascal Jasmin' via Programming" 
<[email protected]> wrote:

> Currently, since all of the time it is a domain error, then Raul is of course 
> right that most of the time its a mistake.  J will let you call =. after =: 
> though, 
>    3 : 'a=. a + 2' 2 
> |value error: a 
> | a=. a+2 
>    a=: 2 
>    3 : 'a=. a + 2' 2 
> 4 
>    a 
> 2 
>    3 : 'a [ a=. a + 2' 2 
> 4 
>    3 : 'a=: a=. a + 2' 2 
> |domain error 
> |   a    =:a=.a+2 
> 
> so, I'm not sure if the possibility of confused intent deserves a domain 
> error just because of the possibility.  The above is often a mistake where 
> the writer forgot to initialize a variable which only gets discovered when 
> you reload the code.  Even if it is intentional, its not a recommended choice 
> for a local variable because you can choose any name, and the name you chose 
> will cause confusion later.
> 
> It appears also that my suggested behaviour already is applied to the base 
> locale, or at least the console.
> 
> My suggestion also, I think, is consistent with the behaviour of most other 
> languages, and provides a way to do something that has no easy workaround.  
> I'd suggest also that most of the time, using =: after =. has the suggested 
> intent, and so it would be doing "what you mean".
> 
> 
> ----- Original Message -----
> From: Don Guinn <[email protected]>
> To: Programming forum <[email protected]>
> Cc: 
> Sent: Thursday, June 19, 2014 4:22:03 PM
> Subject: Re: [Jprogramming] suggestion for =.
> 
> You can refer and modify global names that are shadowed by local names by
> adding the locale to the name.
> 
>    a=:1
> 
>    y=:3
> 
>    lg=: 3 : 0
> 
> smoutput a,y,a__,y__
> 
> 'a y a__ y__'=.4 5 6 7
> 
> a,y,a__,y__
> 
> )
> 
>    lg 2
> 
> 1 2 1 3
> 
> 4 5 6 7
> 
>    a,y
> 
> 6 7
> 
> 
> Notice that adding the locale to the name makes =. work like =: .
> 
> 
> On Thu, Jun 19, 2014 at 12:46 PM, Raul Miller <[email protected]> wrote:
> 
>> I am going to disagree with you here.
>> 
>> The reason =: after =. is an error is because most of the time when that
>> happens it's a mistake. So informing the user of the mistake is the best
>> language design choice for that case.
>> 
>> "Not breaking user code" is a virtue when making changes in a language, but
>> it's not the only relevant issue.
>> 
>> Thanks,
>> 
>> --
>> Raul
>> 
>> 
>> 
>> On Thu, Jun 19, 2014 at 11:53 AM, 'Pascal Jasmin' via Programming <
>> [email protected]> wrote:
>> 
>>> currently the following code generates a domain error at the ('f') =: y
>>>   line.
>>> 
>>> testlocal =: 3 : 0
>>> f =. 33
>>> assign =. 4 : '(x) =: y'
>>> 
>>> 'f' assign f + y
>>> 
>>> ('f') =: f+y
>>> NB. f =: f+y
>>> f
>>> )
>>> 
>>>     testlocal 2
>>> |domain error: testlocal
>>> | ('f') =: f+y
>>>     f
>>> 35
>>> 
>>> the commented line also generates the same error.
>>> 
>>> My suggestion is that all of the above code lines should leave the global
>>> variable f unchanged.  The user benefit is being able to use external
>>> functions that create assignments (can only use =:) with the "shaddowed"
>>> local variable.  Includes benefits of modifying x,y,u,v while only
>>> mentioning the parameter once in a statement, and possibly allowing
>> changes
>>> to values within tacit expressions without relying on global/external
>>> variables.
>>> 
>>> I claim that there would not be any impact to existing user code, because
>>> =: after =. is currently a domain error, and calling an external
>> assignment
>>> function on a name that duplicates a local assignment is more likely to
>> be
>>> unintended behaviour rather than a clever way around the domain error
>> that
>>> would occur under direct global assignment.  Advice to function writers
>> to
>>> name their local variables differently than the globals they access is
>>> under their control.  Though the simple convention of not naming local
>>> variables to the same names as accessed globals is quite sufficient, an
>>> additional workaround could be made that a fully localed name would
>> access
>>> the global.
>>> ----------------------------------------------------------------------
>>> 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