The 'good reason' is speed. (x , y) or (x m} y) in-place may be 10-1000
times faster than not-in-place. Even regular old arithmetic verbs run
about twice as fast when run in-place.
I think you are exaggerating the issue. When I write
a =: b ([ ,~ 3 ,~ ]) a
the one thing I DO expect is that the previous value of (a) will be lost
when the line is executed. Why is it that when the line fails it
suddenly becomes vital to know the original (a)?
Debugging, perhaps. You can turn off the early assignment for
debugging, if you like. Or, you could assign the result to a different
name.
A Milquetoast compromise would have been to suppress the early
assignment unless the user specifies otherwise. But most users wouldn't
know what they were missing, and trillions of CPU cycles would be wasted.
Please give the beta a try, and see if the change causes problems.
Henry Rich
PS. The Dictionary description of parsing and execution is schematic.
Memory-mapped names violate it. Assignment-in-place as previously done
violates it. We have accepted these violations for the performance
benefit they provide; I think the new changes have even higher bang for
the buck.
hr
On 10/3/2016 9:50 PM, Raul Miller wrote:
I mentioned (a=:0](a) because we seem to be talking about changing the
implementation.
Specifically, if we are going to be introducing optimizations which
damage the value of a in some fashion where the interpreter cannot
restore it, I think we should restrict those optimizations to cases
where the code has clearly indicated that damaging a in the error case
is acceptable.
I do not see any good reason for accepting this behavior:
a=: 3 1 4 1 5 9 2
a =: ('b' ,~ 3 ,~ ]) a
|domain error
| a=: ('b',~3,~])a
a
3 1 4 1 5 9 2 3
That is not how J has worked in the past, it does not correspond to
the dictionary description of how parsing works, it seems unnecessary,
and I believe it's only there because of an "optimization".
A problem is: if you optimize for incorrect behavior, you wind up with
something that does the wrong thing, real fast.
And, ok, in some contexts that kind of thing can be an important compromise.
In this case, however, it seems entirely unnecessary.
That said, if you think I have overlooked something important, please
educate me.
Thanks,
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
