My point is that it is easy to intentionally force a copy. If your goal is to make
(u]]) noun not make any copy of noun (with ]), and then check in u whether assignments can be done inplace (yes if they are unrelated to noun) then that is interesting, and may be a significant performance improvement that is worth avoiding the confusing edge "feature"-case for current behaviour. if the current behaviour of (u@:]) is to always copy just because its possible that u might create an in-place modification, then I expect its a gain to conditionally copy only before the inplace modification, based on the refcount criteria you mentioned. its still important that this still remain, and inplace } is ok. (3 : 'y~' [ 3 : '(y) =: 2(0}) y~' ) 'ip' 2 1 2 ----- Original Message ----- From: Henry Rich <henryhr...@gmail.com> To: sou...@jsoftware.com Sent: Tuesday, June 21, 2016 12:01 PM Subject: Re: [Jsource] Language committee: in-place assignment rules Your tests miss the point, I'm afraid. The JE quite often makes copies of arguments. If such a copy is made, the copy will not be affected by the in-place assignment. The cases you show where there is no aliasing may simply be because a copy was made. I would like to reduce the amount of copying (which would increase the number of aliasing problems). Henry Rich On 6/21/2016 11:55 AM, 'Pascal Jasmin' via Source wrote: > A visually useful adverb helps here: > > sfX =: 1 : '][u' > > > ipm sfX ip > 0 1 2 > > this works with deterministic method: (rhs executed first) > > > (ipm ] 3 : 'y~' ) 'ip' > 0 1 2 > (3 : 'y~' [ ipm ) 'ip' > 2 1 2 > ( 3 : '(y) =: 2(0}) y~' ] 3 : 'y~' ) 'ip' > 0 1 2 > (3 : 'y~' [ 3 : '(y) =: 2(0}) y~' ) 'ip' > 2 1 2 > > Its conceivable to want the behaviour, and its easy to avoid. > > In terms of philosophy, I have called bonded dyads dyadically by error more > often than intentionally, often resulting in lockup. But its a cool feature > I have also used intentionally. Removing it will not be considered. > > I think the above has probably had intentional use in the wild, and is easily > bypassed to get the "sane result". Its also easy to deterministically use > the modified "side effect" value by composing on the function. > > > I also can't mess up this expression > > (3 : 'flag =: 1' a:) 3:`[@.] flag =:0 > 3 > > The argument for changing it depends on: > > You could never intentionally want to have a "primarily" side effect function > conditionally "improve" an argument depending on whether it references it. > > > > > ----- Original Message ----- > From: Henry Rich <henryhr...@gmail.com> > To: sou...@jsoftware.com > Sent: Tuesday, June 21, 2016 10:16 AM > Subject: Re: [Jsource] Language committee: in-place assignment rules > > The fix would be to suppress in-place assignment if the name is on the > stack in a higher-level sentence, and would not affect anything that > doesn't use in-place assignment. > > Henry > > > On 6/21/2016 1:32 AM, 'Pascal Jasmin' via Source wrote: >> At first I thought this was 3. normal behaviour >> >> the assignment to ip is independent of the return value (which happens to be >> ip) or the argument value. >> >> >> The issue here though is that (ipm'') gets evaluated prior to ip, which is >> surprising. also happens with: >> >> ((ipm '') ] ]) ip >> 2 1 2 >> >> but good news: >> >> ip =: i. 3 >> (] [ ipm ) ip >> 0 1 2 >> ip >> 2 1 2 >> (ipm ] ]) ip >> >> 0 1 2 >> >> also behaves normally. while these don't. >> >> >> (ipm ] ip"_ ) '' >> 2 1 2 >> (ip [ ipm ) '' >> 2 1 2 >> >> The workaround to get either behaviour is easy. In my first example I think >> the parentheses gets executed before the right tine. >> >> fixing it could be dangerous... could mess with: >> >> inl=:(cocurrent@] ".@] [)"1 0 >> >> ----- Original Message ----- >> From: Henry Rich <henryhr...@gmail.com> >> To: Source forum <sou...@jsoftware.com> >> Sent: Monday, June 20, 2016 10:45 PM >> Subject: [Jsource] Language committee: in-place assignment rules >> >> The issue: >> >> ipm =: 3 : 0 >> >> ip =: 2 (0}) ip >> >> ) >> >> ip =: i. 3 >> >> (ipm '') ] ip >> >> 2 1 2 >> >> >> As you see, ip was modified by call to ipm, which did an in-place >> assignment. This violates the rules, which say that the value of ip >> should have been stacked. In fact, a pointer to the value is stacked. >> >> >> This requires a decision. I think we need a committee of J Language >> Experts to decide how to resolve issues like this, and future enhancements. >> >> >> The choices as I see them are: >> >> 1 - Fix to conform to the Dictionary. Possible; would slow things down >> a little; would make some assignments currently done in-place perform a >> copy. >> >> >> 2 - Ignore it. Leave as is. >> >> >> 3 - Embrace it - declare that in-place assignments to global variables >> may affect previously-stacked references to the same name. [With local >> variables the problem does not arise] >> >> Now we need a Language Committee, and a decision. >> >> >> Henry >> >> >> >> >> >> >> >> ---------------------------------------------------------------------- >> 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
