That fix you describe seems reasonable - I think it winds up being an "in use counter" on each name which, in effect, caches the result that you would get by walking the stack counting references.
Documenting this issue, however, probably warrants some thought. How do you explain to people that the same code will run quickly or slowly depending on the calling environment? Since "global" variable use is also a code correctness and design issue, I do not think the performance issue raised by fix you describe makes it be a bad language design decision (though of course there will be critics of any design decision). Anyways... a quick search suggests a few mentions which probably need elaboration on this subject (perhaps something like: "as of version ___ a problem was resolved where in place assignment conflicted with the dictionary definition. Note also that this means that if a sentence is using a name and calling some code which would otherwise have been doing an in place update of that name that in place assignment would be inconsistent for the caller and does not happen. This is both a performance and a code correctness issue." - but if someone could come up with a better phrasing, that would probably be a good thing). Here's the references I found which will eventually need updating: http://code.jsoftware.com/wiki/Vocabulary/curlyrt http://www.jsoftware.com/help/jforc/modifying_an_array_m.htm http://code.jsoftware.com/wiki/Vocabulary/SpecialCombinations http://www.jsoftware.com/help/jforc/performance_measurement__tip.htm Nothing is ever simple, which I guess is a part of why we put so much effort into trying to make things right... Thanks, -- Raul On Tue, Jun 21, 2016 at 10:16 AM, Henry Rich <henryhr...@gmail.com> wrote: > 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
