The problem with scalar languages with named arrays is that it's too easy to do updates in place in a loop and have an error part-way through the array leaving the array messed up. Declaring an array as non-mutable is a good way to force the programmer to avoid that error. That's not a problem in array languages as either the calculations are successful on the entire array or it fails leaving the resulting array unchanged. As I understand it, the update in place for J is only allowed for verbs that cannot fail part-way through. I looked in the Dictionary and all the rank zero verbs look okay. Other verbs don't look like they lend themselves to update in place anyway. But that's what the beta is for. To make sure that the update in place logic won't result in corrupted arrays.
I'm not familiar with Forth. If it provides looping and updating in place even on unnamed arrays it could result in messed up arrays. On Sun, Oct 2, 2016 at 11:32 AM, Raul Miller <[email protected]> wrote: > My first reaction here was "good point". > > And, then, after a few seconds, I thought of Forth as an example of a > "scalar language" which let's you work with unnamed memory. > > Thanks, > > -- > Raul > > > On Sun, Oct 2, 2016 at 12:45 PM, Don Guinn <[email protected]> wrote: > > > > > > No it's not, but scalar thinking lets people get sloppy on keeping > > dependencies well defined. Thinking in arrays forces one to handle > > dependencies properly. Notice I said > > > > "thinking", not "programming". > > In programming languages like C a name once created and memory location > > are synonymous. So the issue of non-mutable arrays and non-mutable names > > are synonymous. In J they are not. > > > > > > On Oct 2, 2016 8:29 AM, "Raul Miller" <[email protected]> wrote: > > > >> I don't think that scalar languages vs. array languages is the issue, > here. > >> > >> Thanks, > >> > >> -- > >> Raul > >> > >> > >> On Sun, Oct 2, 2016 at 9:32 AM, Don Guinn <[email protected]> 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/forum > >> s.htm > >> >> > > >> >> > > >> >> > ------------------------------------------------------------ > >> ---------- > >> >> > For information about J forums see http://www.jsoftware.com/forum > >> s.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
