[Jprogramming] Early assignment WAS: Non-mutable arrays

[Henry Rich]

Unmodified by the u of u :: v, yes, in case u fails.  When v runs it 
runs like any other verb, possibly executing in place.

Henry Rich

On 10/7/2016 4:57 AM, Erling Hellenäs wrote:
> There is exception handling even inside a tacit expression? In the 
> exception handling procedure the user expects the arguments to be 
> unmodified?
>
> ((1 { 0:) :: 1:) 4
>
> 1
>
> /Erling
>
>
> On 2016-10-06 01:23, 'Pascal Jasmin' via Programming wrote:
>> Just in case I'm not the one misunderstanding,
>>
>> is there a counter example to
>>
>> "There is no possible f such that f N differs from f N =: (anonymous 
>> noun)"
>>
>>
>>
>> ----- Original Message -----
>> From: Henry Rich <henryhrich at gmail.com>
>> To: programming at jsoftware.com
>> Sent: Wednesday, October 5, 2016 3:58 PM
>> Subject: Re: [Jprogramming] Early assignment WAS: Non-mutable arrays
>>
>> All I can say is, It doesn't work that way.  (You have 2 statements,
>> each with 2 versions.  All 4 statements are false.)
>>
>> Henry Rich
>>
>> On 10/5/2016 10:10 AM, 'Pascal Jasmin' via Programming wrote:
>>>> Assignment to (a) increments the usecount, giving (a) a usecount of 2.
>>> I think in the expression,
>>>
>>>
>>> f N =: 1 2 3 NB.(where 1 2 3 is anonymous noun/result)
>>>
>>>
>>> N or 1 2 3 has a use count of 1 here, right after the assignment. 
>>> (more precisely the anonymous "usecount" is freed)
>>>
>>> There is no possible f such that f N differs from f N =: (noun). ie. 
>>> the line is always identical to the 2 lines
>>>
>>> N =: (noun)
>>> f N
>>>
>>>
>>>
>>>
>>> ----- Original Message -----
>>> From: Henry Rich <henryhrich at gmail.com>
>>> To: programming at jsoftware.com
>>> Sent: Tuesday, October 4, 2016 10:42 PM
>>> Subject: Re: [Jprogramming] Early assignment WAS: Non-mutable arrays
>>>
>>> Yes, you're right, I misanalyzed.  It goes like this:
>>>
>>> 1 2 3 starts with a usecount of 1, and a mark to indicate that the
>>> usecount should be decremented when the sentence completes. [When the
>>> usecount is decremented to 0 the block is freed].
>>>
>>> Assignment to (a) increments the usecount, giving (a) a usecount of 2.
>>> That makes (a) ineligible for in-place operations.
>>>
>>>
>>> Henry Rich
>>>
>>>
>>> On 10/4/2016 10:21 PM, 'Pascal Jasmin' via Programming wrote:
>>>> this didn't seem to work in beta 12 (latest all in one installer)
>>>>
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: Henry Rich <henryhrich at gmail.com>
>>>> To: programming at jsoftware.com
>>>> Sent: Tuesday, October 4, 2016 10:14 PM
>>>> Subject: Re: [Jprogramming] Early assignment WAS: Non-mutable arrays
>>>>
>>>> Yes, this is executed in-place.
>>>>
>>>> In general, an assignment to a name whose value is not in use in 
>>>> another
>>>> name causes that value to become eligible for in-place execution (with
>>>> the possibility of early assignment) as long as the execution stack
>>>> contains nothing beyond the value to be assigned.
>>>>
>>>> a=: ('b' ,~ 4,~])a =: 1 2 3    NB. in place
>>>>
>>>> (a=: ('b' ,~ 4,~])a =: 1 2 3) [ 1    NB. not in place
>>>>
>>>> Henry Rich
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 10/4/2016 9:28 PM, 'Pascal Jasmin' via Programming wrote:
>>>>> 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 <henryhrich at gmail.com>
>>>>> To: programming at jsoftware.com
>>>>> 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 <rauldmiller at gmail.com> 
>>>>>>> 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 
>>>>>>>> <henryhrich at gmail.com> 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
>>>> ----------------------------------------------------------------------
>>>> 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
>> ----------------------------------------------------------------------
>> For information about J forums see http://www.jsoftware.com/forums.htm
>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm