IMO the dependence of so many preconditions that affects the behavior is convoluted and unhelpful. Or at least these preconditions should be fine tuned or overrided by some 9!:53 options.
On Oct 5, 2016 7:25 AM, "Henry Rich" <[email protected]> wrote: > The whole point of operation in place is to avoid having to copy an > in-placeable argument; copying the argument would not be a good solution. > > After hearing the screams and dodging the dead cats, I have some proposals: > > 1. Early assignment (which is what we'll call the act of assigning an > intermediate value to a name that is about to be reassigned) will apply > only for sentences executed from an explicit definition. That will > eliminate the most likely source of confusion, which is erroneous sentences > typed into the console during debugging and exploration. > > For discussion here: > > 2. Early assignment could be disabled for sentences executed between try. > and catch. This would apply only to sentences from the same execution that > contains the try. Verbs called from within the try. block will continue to > have early assignment enabled as specified by the setting of 9!:52''. > > 3. Error message text could be modified to indicate that an early > assignment occurred. I worry about this because existing code might rely > on the text of messages. > > Henry Rich > > > On 10/4/2016 3:01 PM, Louis de Forcrand wrote: > >> 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 >> > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
