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
