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
