I second Raul; the behaviour described is very counter-intuitive. Maybe add a third setting to 9!:53 which copies a at the start of a tacit verb involving in place operations?
Also, what is the current (j804) behaviour when an in-place ammend fails? Since there's only one operation, if it fails a shouldn't be modified should it? If so, copying a at the beginning of a tacit verb containing more than one in-place operation (IPO) should always be faster than the current implementation, since copying would only be needed when two or more IPOs take place. Louis > On 04 Oct 2016, at 07:15, Raul Miller <[email protected]> wrote: > > When there are many verbs involved, it seems like the relative cost to > make a copy of the original at the start should be minor. > > Thanks, > > -- > Raul > > >> On Mon, Oct 3, 2016 at 10:52 PM, Henry Rich <[email protected]> wrote: >> The shape is just the tip of the iceberg. If the verb in question were m}, >> there would be no way to restore (a). >> >> And in general, many in-place verbs may have executed before the error. The >> original (a) may be long gone. >> >> If you foresee this as a problem, you should execute 9!:53(0) to turn off >> early assignment. >> >> Henry Rich >> >>> On 10/3/2016 10:34 PM, Raul Miller wrote: >>> >>> 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, >> >> ---------------------------------------------------------------------- >> 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
