Hi all !
This is how I understood immutable arrays after reading about them and
doing some small tests:
-An immutable array class is similar to a copy-on-write filesystem. You
can get a copy without doing any copying. When you start changing the
files, the changed files are copied to the area of the new filesystem.
-With the immutable array class, array pieces of maybe 32 items are the
items corresponding to the files in the COW filesystem. If you change
one of the 32 items all of them are copied to the new allocation area.
Non-changed pieces remain in the old allocation area.
-You can get a mutable copy of the array, change it, and then make it
immutable before you return it.
-You can operate on the whole immutable array and get a new array.
The immutable array class is a general solution you can use to avoid
in-place changes, as far as I understand. The question is what is best,
implementing in-place operations or using an immutable array class.
Cheers,
Erling Hellenäs
On 2016-10-02 22:42, Henry Rich wrote:
Yes, 9!:53 (0).
Henry Rich
On 10/2/2016 4:16 PM, 'Pascal Jasmin' via Programming wrote:
Interesting, you mentioned there is also a new foreign to avoid this?
the least surprising behaviour for
a =: someverbwitherror a
is that `a` is unchanged.
----- Original Message -----
From: Henry Rich <[email protected]>
To: [email protected]
Sent: Sunday, October 2, 2016 4:09 PM
Subject: Re: [Jprogramming] Non-mutable arrays
Here's how it looks in J8.05 (I have changed the example slightly
because ([ ,~ 3 ,~ ]) does not yet get the full in-place treatment, but
it will soon):
a=: 3 1 4 1 5 9 2
a =: ('b' ,~ 3 ,~ ]) a
|domain error
| a=: ('b',~3,~])a
a
3 1 4 1 5 9 2 3
The 3 was appended to (a) in place; JE tried to append the 'b' as well
(in place), but that failed, leaving (a) holding the result of the first
append.
I said 'b will be appended in place', meaning the value of (b) will be
appended to that of (a). (Alternatively, 'a will be appended to in
place')
'All' refers to the two append operations.
Henry Rich
On 10/2/2016 3:49 PM, Roger Hui wrote:
You must be talking about the new release of J, right? I tried the
following in J64-602 and got the following:
a=: 3 1 4 1 5 9
b=: 'foo upon thee'
a =: b ([ ,~ 3 ,~ ]) a
|domain error
| a=:b ([,~3,~])a
a
3 1 4 1 5 9
b
foo upon thee
the 3 will be appended in place to the end of a, then b will be
appended. All in place.
Can you please elaborate/clarify? If it is "all in place" then the
semantics has changed. To be precise, I would be surprised if b is
appended in place, that b would be changed at all. Depends on what you
mean by "b will be appended" and what the "all" refers to. (Ha, I
get to
nitpick other people's wording for a change. :-)
On Sun, Oct 2, 2016 at 7:54 AM, Henry Rich <[email protected]>
wrote:
Ah, but what does 'half-modified' mean? If you do
a =: b ([ ,~ 3 ,~ ]) a
the 3 will be appended in place to the end of a, then b will be
appended.
All in place.
Suppose b has the wrong type. Then appending it will fail, and a
will be
left with the 3 on the end.
We decided to make this the default behavior. There's a foreign
that will
suppress reassignment within compounds, forcing these appends to run
not-in-place.
Henry Rich
On 10/2/2016 9:32 AM, Don Guinn wrote:
Scalar languages have a need for non-mutable arrays. Array
languages do
not. As Bill said, all arrays in J are non-mutable. But names are
not. As
I
understand it, the in-place operations are allowed only for
actions that
cannot fail part-way through leaving an array half-modified.
On Sun, Oct 2, 2016 at 5:13 AM, bill lam <[email protected]> wrote:
I think other forum members should have answer your question,
All J array are non-mutable. eg, an array 0 1 2 cannot becomes
0 1 2 3 or 0 1. But value assigned to a name can change.
If you meant a name can only be assigned a value once, it was
called "given name" in ancient J, and was dropped long time ago.
I might not recall correctly, that was 2 or 3 decades ago.
In-place operation is an implementation detail not a language
feature.
Вс, 02 окт 2016, Erling Hellenäs написал(а):
No - I wish I knew somewhere this is clearly described. What I
think is
that
in functional languages with non-mutable data we can avoid locking.
Non-mutable data simplifies parallelization since the objects we
work on
never change. It enables massive parallelization without any
locking
schemes, I think. I hope someone in the forum can describe this
better
or
link to some nice description. /Erling
On 2016-10-01 23:28, Henry Rich wrote:
It sounds like you are conflating 'mutex' and 'mutable'.
Henry Rich
On 10/1/2016 4:15 PM, Erling Hellenäs wrote:
I think non-mutable data is part of the solution to the locking
problems in object-oriented languages. It seems there must be a
limit after which even J has to use more than one thread? Is
there a
plan for how to handle that? Or are we using several threads
already? /Erling
On 2016-10-01 21:56, Erling Hellenäs wrote:
On 2016-10-01 15:40, 'Pascal Jasmin' via Programming wrote:
Forcing immutable only arrays is not an option for this
language if it is to remain compatible with itself
Someone wants to give a more specific explanation to this? What
in the language prevents immutable only arrays?
/Erling
------------------------------------------------------------
----------
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
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3
----------------------------------------------------------------------
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
