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
