another method is the copy by value for jmf, eg
a:{a
On Oct 4, 2016 7:22 AM, "Raul Miller" <[email protected]> wrote:
> 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
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
