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