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
