> 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 <[email protected]> To: [email protected] 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 <[email protected]> > To: [email protected] > 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 <[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 > ---------------------------------------------------------------------- > 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
