I made different suggestions in my beta post. namely, this expression should
also be optimized:
a=: ('b' ,~ 4,~])a =: 1 2 3
if possible, early assignment should also apply in scripts (even if through
tacit expressions).
In general though, I think the advice "assign to new name to be safe", works
ok, but above line in console can be edited and reapplied with consistent
results.
----- Original Message -----
From: Henry Rich <[email protected]>
To: [email protected]
Sent: Tuesday, October 4, 2016 7:25 PM
Subject: [Jprogramming] Early assignment WAS: Non-mutable arrays
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
