This has been bothering me. After sleeping on it, I think I know how to articulate my concerns:
It seems unnecessary. First, the error handling in this case could restore the shape of a to its original value and that seems like it should be simple. However, also, in hypothetical analogous cases where error recovery would be difficult, there's another approach that could be used: replace the reference to a with (a=:0)](a) This frees a's reference to the array, and makes it clear, also, that it's good to destroy a when an error occurs. a =: b ([ ,~ 3 ,~ ]) (a=:0)](a) (Note also that the parenthesis around a are not optional here. There are other expressions which achieve the same effect, but you can't use just a bare a there and have it work right.) Thanks, -- Raul On Sun, Oct 2, 2016 at 10: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
