There are two reasons to be concerned about the value of a in the error case.
The minor one is error recovery. This is a simple example, and easy to understand. What happens, though, when someone uses try./catch. with a large code base? This issue would not be easy to isolate, nor will it be easy to understand. A bigger issue is the one you mentioned here: debugging. When debugging code which takes a long time to run, you will at times want to fix the issue and continue, rather than burning the time necessary to restart from the beginning. And, also, this seems like it will be hard to explain and at the same time distract from issues which are more important. But keep in mind that I am not recommending the (a=:0)](a) mechanism for this example. I made that suggestion for hypothetical cases. I am instead recommending that the shape of a be saved somewhere and that a have its shape set to what it originally was, in the error case. Is there some reason why you think that restoring a's shape in the error case is not a viable approach here? Thanks, -- Raul On Mon, Oct 3, 2016 at 10:19 PM, Henry Rich <[email protected]> wrote: > 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
