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

Reply via email to