Because of the constraints J already has in place, when doing an "in place array update", if there were an error, the array would be discarded. So that's a good thought, but I think we're good here.
And, yes, Forth allows looping and updating in place on unnamed arrays. So that's something that has to be dealt with by the programmer. That said, I remember reading that Excel was originally written in Forth. So, there's that. Thanks, -- Raul On Sun, Oct 2, 2016 at 3:02 PM, Don Guinn <[email protected]> wrote: > 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
