From peter.mckinna at gmail.com Thu Mar 1 12:57:14 2018 From: peter.mckinna at gmail.com (Peter McKinna) Date: Thu, 1 Mar 2018 22:57:14 +1100 Subject: [M3devel] bits for Message-ID: Hi, VAR x : BITS 1 FOR [0..2]; is allowed by the compiler but I think its a bug. Surely you need 2 bits to store a 2 Same with BITS 2 FOR [0..4]; etc Looks like an off by one sort of problem. Regards Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sat Mar 3 16:58:24 2018 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 3 Mar 2018 09:58:24 -0600 Subject: [M3devel] bits for In-Reply-To: References: Message-ID: Sure sounds like a bug to me. I'll look at it. On 03/01/2018 05:57 AM, Peter McKinna wrote: > Hi, > > VAR > x : BITS 1 FOR [0..2]; > > is allowed by the compiler but I think its a bug. Surely you need 2 bits to store a 2 > Same with BITS 2 FOR [0..4]; etc > > Looks like an off by one sort of problem. > > Regards Peter > > > > > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Wed Mar 21 19:22:53 2018 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 21 Mar 2018 13:22:53 -0500 Subject: [M3devel] A bizarre language quirk Message-ID: <84cdfcdd-eebc-e937-cb08-1f1d31ebe299@lcwb.coop> Modula3, 2.6.3 (Designators), concerning subscripting says: An expression of the form a[i_1, ..., i_n] is shorthand for a[i_1]...[i_n]. And: If a is a reference to an array, then a[i] is shorthand for a^[i]. These have the unfortunate (and maybe unintended?) interaction that a[i_1][i_2] could subscript a 2-d array, or it could mean a[i_1]^[i_2], if a is an array of pointers to arrays. The compiler handles either, as determined by the type of a. But the compiler discards the distinction between a[i_1,i_2] and a[i_1][i_2] at parse time, converting the former to the the latter. This in turn means it will also interpret a[i_1,i_2] as a[i_1]^[i_2] if the type of a calls for it. As written, the language allows this. A rewrite using each of the language shorthand rules in the order given does it. But this seems utterly bizarre, and a horrible case of syntactic misleadingness. Anybody aware of existing code that would be undermined by making the compiler refuse the latter interpretation? I have long been very skeptical about the wisdom of allowing the implied dereference, even with only one subscript. But discovering this leaves me with no longer any doubt that it is a bad idea. The only benefit is saving a single keystroke for the writer, who has the context well in mind already and only does this once. The cost is considerably greater difficulty to readers' & maintainers' understanding what it means. They often don't have the context without searching, possibly widely, in the code. And this is liable to happen several times. -- Rodney Bates rodney.m.bates at acm.org From lemming at henning-thielemann.de Wed Mar 21 20:57:14 2018 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 21 Mar 2018 20:57:14 +0100 (CET) Subject: [M3devel] A bizarre language quirk In-Reply-To: <84cdfcdd-eebc-e937-cb08-1f1d31ebe299@lcwb.coop> References: <84cdfcdd-eebc-e937-cb08-1f1d31ebe299@lcwb.coop> Message-ID: On Wed, 21 Mar 2018, Rodney M. Bates wrote: > Modula3, 2.6.3 (Designators), concerning subscripting says: > > An expression of the form a[i_1, ..., i_n] is shorthand for a[i_1]...[i_n]. I think I wrote earlier about this shorthand ... I found the following problem: ARRAY OF ARRAY OF Something is syntactically not quite a 2D-array since as it is written it suggests that the sub-arrays may have different sizes. This has practical consequences. It would be no problem to have a 0-by-n array. But Modula-3 fails to determine the size of the second dimension of a 0-by-n array, because LAST(a[0]) is a range violation in the first dimension. From rodney_bates at lcwb.coop Sat Mar 24 16:53:26 2018 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 24 Mar 2018 10:53:26 -0500 Subject: [M3devel] Fwd: Re: A bizarre language quirk In-Reply-To: <6cb9a420-315e-cf31-f789-1c8cc86746c4@lcwb.coop> References: <6cb9a420-315e-cf31-f789-1c8cc86746c4@lcwb.coop> Message-ID: <02ab06b7-28cb-3b34-47ad-ec4b7c3665b4@lcwb.coop> On 03/21/2018 02:57 PM, Henning Thielemann wrote: > > On Wed, 21 Mar 2018, Rodney M. Bates wrote: > >> Modula3, 2.6.3 (Designators), concerning subscripting says: >> >> An expression of the form a[i_1, ..., i_n] is shorthand for a[i_1]...[i_n]. > > I think I wrote earlier about this shorthand ... > > I found the following problem: > > ARRAY OF ARRAY OF Something > > is syntactically not quite a 2D-array since as it is written it suggests that the sub-arrays may have different sizes. It never occurred to me that this syntax could suggest it could be a ragged array, probably because I was already familiar with the (fixed) array-of-array concept being truly 2D in Pascal and Modula2. I do see in 2.2.3, in the first paragraph: "The elements all have the same size and the same type, called the _element type_ of the array", this sentence applying to both fixed and open arrays. This probably should be clarified, since "size" seems not very precise here. Maybe "element count", which would be harmlessly redundant in the case of a fixed array. Two paragraphs later, the definition of array _shape_ seems also to imply the array is not ragged, but this is perhaps too subtle not to be made explicit somewhere. > This has practical consequences. It would be no problem to have a 0-by-n array. But Modula-3 fails >to determine the size of the second dimension of a 0-by-n array, because LAST(a[0]) is a range >violation in the first dimension. But a[0] doesn't exist, so what would be a meaningful definition of its size or bounds? Even if you could somehow define and discover it, you can't do anything else with a[0] either. The only way I can think of create such a thing would be a zero-length SUBARRAY of an mxn array. Neither the language nor the compiler disallow a a zero-length SUBARRAY. a could alias the original mxn array, but only an empty portion of it. Other than copying and passing a around by reference, there is no meaningful definition of any operation on a. > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel > -- Rodney Bates rodney.m.bates at acm.org From lists at darko.org Sat Mar 24 17:41:40 2018 From: lists at darko.org (Darko Volaric) Date: Sat, 24 Mar 2018 17:41:40 +0100 Subject: [M3devel] Fwd: Re: A bizarre language quirk In-Reply-To: <02ab06b7-28cb-3b34-47ad-ec4b7c3665b4@lcwb.coop> References: <6cb9a420-315e-cf31-f789-1c8cc86746c4@lcwb.coop> <02ab06b7-28cb-3b34-47ad-ec4b7c3665b4@lcwb.coop> Message-ID: While we're on the subject, there's a compiler bug in there somewhere: CONST A = ARRAY OF ARRAY OF INTEGER{ARRAY OF INTEGER{1}}; compiles but CONST A = ARRAY OF ARRAY OF INTEGER{ARRAY OF INTEGER{}}; results in *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/exprs/ArrayExpr.m3", line 653 *** This may be the same or a related bug: TYPE R = RECORD a := 1 END; CONST B = ARRAY OF R{R{}}; CONST C = B[0].a; (* error: value is not constant *) but TYPE R = RECORD a := 1 END; CONST B = ARRAY OF R{R{1}}; CONST C = B[0].a; (* no error *) Back on topic, although I can understand you not liking the construct, given that it's unlikely to make someone to write incorrect code (dereferencing is the only possible operation and is required), is it worth breaking existing code? Not knowing of its use anywhere isn't definitive. On Sat, Mar 24, 2018 at 4:53 PM, Rodney M. Bates wrote: > > > > On 03/21/2018 02:57 PM, Henning Thielemann wrote: > >> >> On Wed, 21 Mar 2018, Rodney M. Bates wrote: >> >> Modula3, 2.6.3 (Designators), concerning subscripting says: >>> >>> An expression of the form a[i_1, ..., i_n] is shorthand for >>> a[i_1]...[i_n]. >>> >> >> I think I wrote earlier about this shorthand ... >> >> I found the following problem: >> >> ARRAY OF ARRAY OF Something >> >> is syntactically not quite a 2D-array since as it is written it suggests >> that the sub-arrays may have different sizes. >> > > It never occurred to me that this syntax could suggest it could be a > ragged array, probably because > I was already familiar with the (fixed) array-of-array concept being truly > 2D in Pascal and Modula2. > > I do see in 2.2.3, in the first paragraph: "The elements all have the same > size and the same type, > called the _element type_ of the array", this sentence applying to both > fixed and open arrays. > This probably should be clarified, since "size" seems not very precise > here. Maybe "element count", > which would be harmlessly redundant in the case of a fixed array. > > Two paragraphs later, the definition of array _shape_ seems also to imply > the array is not ragged, > but this is perhaps too subtle not to be made explicit somewhere. > > This has practical consequences. It would be no problem to have a 0-by-n >> array. But Modula-3 fails >> to determine the size of the second dimension of a 0-by-n array, because >> LAST(a[0]) is a range >> violation in the first dimension. >> > > But a[0] doesn't exist, so what would be a meaningful definition of its > size or bounds? Even if you > could somehow define and discover it, you can't do anything else with a[0] > either. > > The only way I can think of create such a thing would be a zero-length > SUBARRAY of an mxn array. > Neither the language nor the compiler disallow a a zero-length SUBARRAY. > a could alias the > original mxn array, but only an empty portion of it. Other than copying > and passing a around > by reference, there is no meaningful definition of any operation on a. > > _______________________________________________ >> M3devel mailing list >> M3devel at elegosoft.com >> https://m3lists.elegosoft.com/mailman/listinfo/m3devel >> >> > -- > Rodney Bates > rodney.m.bates at acm.org > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sat Mar 24 19:11:20 2018 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 24 Mar 2018 13:11:20 -0500 Subject: [M3devel] A bizarre language quirk In-Reply-To: References: <84cdfcdd-eebc-e937-cb08-1f1d31ebe299@lcwb.coop> Message-ID: There is a related problem with trying to construct ragged arrays using constructors: ; TYPE O = ARRAY OF INTEGER ; TYPE OO = ARRAY OF O ; CONST Ragged1 = OO { O { 3 , 7 } , O { 11 } } I find nothing in the language to prohibit this, despite the fact that it is not in the value set of multi-dimensional arrays as defined. The compiler quietly fills out Ragged1[1,1] with zero, or maybe it's really random. Several other combinations crash the compiler in CG, including making the second O longer than the first and providing an O that does not have static element count. On 03/21/2018 02:57 PM, Henning Thielemann wrote: > > On Wed, 21 Mar 2018, Rodney M. Bates wrote: > >> Modula3, 2.6.3 (Designators), concerning subscripting says: >> >> An expression of the form a[i_1, ..., i_n] is shorthand for a[i_1]...[i_n]. > > I think I wrote earlier about this shorthand ... > > I found the following problem: > > ARRAY OF ARRAY OF Something > > is syntactically not quite a 2D-array since as it is written it suggests that the sub-arrays may have different sizes. > > This has practical consequences. It would be no problem to have a 0-by-n array. But Modula-3 fails to determine the size of the second dimension of a 0-by-n array, because LAST(a[0]) is a range violation in the first dimension. > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Sat Mar 24 19:18:39 2018 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 24 Mar 2018 13:18:39 -0500 Subject: [M3devel] Fwd: Re: A bizarre language quirk In-Reply-To: References: <6cb9a420-315e-cf31-f789-1c8cc86746c4@lcwb.coop> <02ab06b7-28cb-3b34-47ad-ec4b7c3665b4@lcwb.coop> Message-ID: <01d462b5-37f6-061b-3c6f-ab6978bc9559@lcwb.coop> On 03/24/2018 11:41 AM, Darko Volaric wrote: > While we're on the subject, there's a compiler bug in there somewhere: > > CONST A = ARRAY OF ARRAY OF INTEGER{ARRAY OF INTEGER{1}}; > > compiles but > > CONST A = ARRAY OF ARRAY OF INTEGER{ARRAY OF INTEGER{}}; > > results in > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/exprs/ArrayExpr.m3", line 653 > *** > > This may be the same or a related bug: > > TYPE R = RECORD a := 1 END; > CONST B = ARRAY OF R{R{}}; > CONST C = B[0].a; (* error: value is not constant *) > > but > > TYPE R = RECORD a := 1 END; > CONST B = ARRAY OF R{R{1}}; > CONST C = B[0].a; (* no error *) > > I'll add these to my list. I've been working on this area for some time, trying to get rid of CG crashes, etc. > > Back on topic, although I can understand you not liking the construct, given that it's unlikely to make someone to write incorrect code (dereferencing is the only possible operation and is required), is it worth breaking existing code? Not knowing of its use anywhere isn't definitive. > Sigh. OK. But i's sure C++-ish in harassing a maintainer by making something look significantly different from what it really is. > > On Sat, Mar 24, 2018 at 4:53 PM, Rodney M. Bates > wrote: > > > > > On 03/21/2018 02:57 PM, Henning Thielemann wrote: > > > On Wed, 21 Mar 2018, Rodney M. Bates wrote: > > Modula3, 2.6.3 (Designators), concerning subscripting says: > > An expression of the form a[i_1, ..., i_n] is shorthand for a[i_1]...[i_n]. > > > I think I wrote earlier about this shorthand ... > > I found the following problem: > > ARRAY OF ARRAY OF Something > > is syntactically not quite a 2D-array since as it is written it suggests that the sub-arrays may have different sizes. > > > It never occurred to me that this syntax could suggest it could be a ragged array, probably because > I was already familiar with the (fixed) array-of-array concept being truly 2D in Pascal and Modula2. > > I do see in 2.2.3, in the first paragraph: "The elements all have the same size and the same type, > called the _element type_ of the array", this sentence applying to both fixed and open arrays. > This probably should be clarified, since "size" seems not very precise here. Maybe "element count", > which would be harmlessly redundant in the case of a fixed array. > > Two paragraphs later, the definition of array _shape_ seems also to imply the array is not ragged, > but this is perhaps too subtle not to be made explicit somewhere. > > This has practical consequences. It would be no problem to have a 0-by-n array. But Modula-3 fails > to determine the size of the second dimension of a 0-by-n array, because LAST(a[0]) is a range > violation in the first dimension. > > > But a[0] doesn't exist, so what would be a meaningful definition of its size or bounds? Even if you > could somehow define and discover it, you can't do anything else with a[0] either. > > The only way I can think of create such a thing would be a zero-length SUBARRAY of an mxn array. > Neither the language nor the compiler disallow a a zero-length SUBARRAY. a could alias the > original mxn array, but only an empty portion of it. Other than copying and passing a around > by reference, there is no meaningful definition of any operation on a. > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel > > > -- > Rodney Bates > rodney.m.bates at acm.org > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel > > -- Rodney Bates rodney.m.bates at acm.org From lists at darko.org Sat Mar 24 19:29:40 2018 From: lists at darko.org (Darko Volaric) Date: Sat, 24 Mar 2018 19:29:40 +0100 Subject: [M3devel] Fwd: Re: A bizarre language quirk In-Reply-To: <01d462b5-37f6-061b-3c6f-ab6978bc9559@lcwb.coop> References: <6cb9a420-315e-cf31-f789-1c8cc86746c4@lcwb.coop> <02ab06b7-28cb-3b34-47ad-ec4b7c3665b4@lcwb.coop> <01d462b5-37f6-061b-3c6f-ab6978bc9559@lcwb.coop> Message-ID: I've got more on the partial revelation side of things. Maybe we should use the "issues" section of the GIthub repository to manage these and allow others to work on them, should they be inclined. On Sat, Mar 24, 2018 at 7:18 PM, Rodney M. Bates wrote: > > > On 03/24/2018 11:41 AM, Darko Volaric wrote: > >> While we're on the subject, there's a compiler bug in there somewhere: >> >> CONST A = ARRAY OF ARRAY OF INTEGER{ARRAY OF INTEGER{1}}; >> >> compiles but >> >> CONST A = ARRAY OF ARRAY OF INTEGER{ARRAY OF INTEGER{}}; >> >> results in >> >> *** >> *** runtime error: >> *** <*ASSERT*> failed. >> *** file "../src/exprs/ArrayExpr.m3", line 653 >> *** >> >> This may be the same or a related bug: >> >> TYPE R = RECORD a := 1 END; >> CONST B = ARRAY OF R{R{}}; >> CONST C = B[0].a; (* error: value is not constant *) >> >> but >> >> TYPE R = RECORD a := 1 END; >> CONST B = ARRAY OF R{R{1}}; >> CONST C = B[0].a; (* no error *) >> >> >> > I'll add these to my list. I've been working on this area for some time, > trying to get > rid of CG crashes, etc. > > >> Back on topic, although I can understand you not liking the construct, >> given that it's unlikely to make someone to write incorrect code >> (dereferencing is the only possible operation and is required), is it worth >> breaking existing code? Not knowing of its use anywhere isn't definitive. >> >> > Sigh. OK. But i's sure C++-ish in harassing a maintainer by making > something look significantly > different from what it really is. > > >> On Sat, Mar 24, 2018 at 4:53 PM, Rodney M. Bates > > wrote: >> >> >> >> >> On 03/21/2018 02:57 PM, Henning Thielemann wrote: >> >> >> On Wed, 21 Mar 2018, Rodney M. Bates wrote: >> >> Modula3, 2.6.3 (Designators), concerning subscripting says: >> >> An expression of the form a[i_1, ..., i_n] is shorthand for >> a[i_1]...[i_n]. >> >> >> I think I wrote earlier about this shorthand ... >> >> I found the following problem: >> >> ARRAY OF ARRAY OF Something >> >> is syntactically not quite a 2D-array since as it is written it >> suggests that the sub-arrays may have different sizes. >> >> >> It never occurred to me that this syntax could suggest it could be a >> ragged array, probably because >> I was already familiar with the (fixed) array-of-array concept being >> truly 2D in Pascal and Modula2. >> >> I do see in 2.2.3, in the first paragraph: "The elements all have the >> same size and the same type, >> called the _element type_ of the array", this sentence applying to >> both fixed and open arrays. >> This probably should be clarified, since "size" seems not very >> precise here. Maybe "element count", >> which would be harmlessly redundant in the case of a fixed array. >> >> Two paragraphs later, the definition of array _shape_ seems also to >> imply the array is not ragged, >> but this is perhaps too subtle not to be made explicit somewhere. >> >> This has practical consequences. It would be no problem to have a >> 0-by-n array. But Modula-3 fails >> to determine the size of the second dimension of a 0-by-n array, >> because LAST(a[0]) is a range >> violation in the first dimension. >> >> >> But a[0] doesn't exist, so what would be a meaningful definition of >> its size or bounds? Even if you >> could somehow define and discover it, you can't do anything else with >> a[0] either. >> >> The only way I can think of create such a thing would be a >> zero-length SUBARRAY of an mxn array. >> Neither the language nor the compiler disallow a a zero-length >> SUBARRAY. a could alias the >> original mxn array, but only an empty portion of it. Other than >> copying and passing a around >> by reference, there is no meaningful definition of any operation on a. >> >> _______________________________________________ >> M3devel mailing list >> M3devel at elegosoft.com >> https://m3lists.elegosoft.com/mailman/listinfo/m3devel < >> https://m3lists.elegosoft.com/mailman/listinfo/m3devel> >> >> >> -- >> Rodney Bates >> rodney.m.bates at acm.org >> >> _______________________________________________ >> M3devel mailing list >> M3devel at elegosoft.com >> https://m3lists.elegosoft.com/mailman/listinfo/m3devel < >> https://m3lists.elegosoft.com/mailman/listinfo/m3devel> >> >> >> > -- > Rodney Bates > rodney.m.bates at acm.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Sat Mar 24 19:49:30 2018 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 24 Mar 2018 19:49:30 +0100 (CET) Subject: [M3devel] ARRAY OF ARRAY (Re: A bizarre language quirk) In-Reply-To: <6cb9a420-315e-cf31-f789-1c8cc86746c4@lcwb.coop> References: <84cdfcdd-eebc-e937-cb08-1f1d31ebe299@lcwb.coop> <6cb9a420-315e-cf31-f789-1c8cc86746c4@lcwb.coop> Message-ID: On Fri, 23 Mar 2018, Rodney M. Bates wrote: > On 03/21/2018 02:57 PM, Henning Thielemann wrote: >> >> On Wed, 21 Mar 2018, Rodney M. Bates wrote: >> >>> Modula3, 2.6.3 (Designators), concerning subscripting says: >>> >>> An expression of the form a[i_1, ..., i_n] is shorthand for >>> a[i_1]...[i_n]. >> >> I think I wrote earlier about this shorthand ... >> >> I found the following problem: >> >> ARRAY OF ARRAY OF Something >> >> is syntactically not quite a 2D-array since as it is written it suggests >> that the sub-arrays may have different sizes. > > It never occurred to me that this syntax could suggest it could be a > ragged array, probably because I was already familiar with the (fixed) > array-of-array concept being truly 2D in Pascal and Modula2. I did not have problems in understanding the Modula-3 report, instead I consider it a flaw in the syntax and it has practical consequences. Why can I choose in ARRAY OF ARRAY only the size of the outer array freely and the sizes of the inner arrays are constrained? Where is the composability of type constructors? And what is the size of the inner arrays if there are no inner arrays? What else would be the type of a ragged array, if not ARRAY OF ARRAY OF T? In Haskell "Array Int (Array Int a)" would be actually a ragged array (in Haskell all objects are actually pointers to objects) and a rectangular 2D-array would have the type "Array (Int,Int) a". >> This has practical consequences. It would be no problem to have a 0-by-n >> array. But Modula-3 fails >> to determine the size of the second dimension of a 0-by-n array, because >> LAST(a[0]) is a range >> violation in the first dimension. > > But a[0] doesn't exist, so what would be a meaningful definition of its > size or bounds? Even if you could somehow define and discover it, you > can't do anything else with a[0] either. I want to get the extent of the 2D array without accessing any element. The array size must be stored separated from the elements anyway. I encountered the problem when working with (row-major) matrices with zero columns. E.g. this simple loop FOR i:=FIRST(a[0]) TO LAST(a[0]) DO sum:=0; FOR j:=FIRST(a) TO LAST(a) DO sum:=sum+a[j,i]; END; b[i]:=sum; END; fails for a 0-by-n array because of the access to a[0]. But technically there is no need to reference a[0] because the size of a[0] is not stored in a[0] or any other a[i], but in 'a'. Syntax suggests that NUMBER(a[0]) and NUMBER(a[1]) could be different but they cannot. The syntax of 2D arrays in Modula-3 actually corresponds to ragged arrays. A syntax for rectangular two-dimensional arrays might be like: ARRAY *,* OF T or even mixed: ARRAY *,[0..9],* OF T A 3D array with ragged arrays in the last dimension would be: ARRAY *,* OF ARRAY OF T Elements might be accessed by a[i,j] It would still be useful to let a[i] denote a slice of the array. Then a[i][j] would still be allowed. Also NUMBER(a[i]) would still be allowed but it should not be necessary to access a[i]. Instead there might be a variation of NUMBER, like: NUMBER(a,0) and NUMBER(a,1) to access the extents in the two dimensions without accessing a potentially non-existent slice. The above loop would become: FOR i:=FIRST(a,1) TO LAST(a,1) DO sum:=0; FOR j:=FIRST(a,0) TO LAST(a,0) DO sum:=sum+a[j,i]; END; b[i]:=sum; END; and it would work for 0-by-n arrays, too. From hendrik at topoi.pooq.com Sat Mar 24 20:10:55 2018 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Sat, 24 Mar 2018 15:10:55 -0400 Subject: [M3devel] ARRAY OF ARRAY (Re: A bizarre language quirk) In-Reply-To: References: <84cdfcdd-eebc-e937-cb08-1f1d31ebe299@lcwb.coop> <6cb9a420-315e-cf31-f789-1c8cc86746c4@lcwb.coop> Message-ID: <20180324191055.GA7629@topoi.pooq.com> On Sat, Mar 24, 2018 at 07:49:30PM +0100, Henning Thielemann wrote: > > On Fri, 23 Mar 2018, Rodney M. Bates wrote: > > >On 03/21/2018 02:57 PM, Henning Thielemann wrote: > >> > >>On Wed, 21 Mar 2018, Rodney M. Bates wrote: > >> > >>>Modula3, 2.6.3 (Designators), concerning subscripting says: > >>> > >>>An expression of the form a[i_1, ..., i_n] is shorthand for > >>>a[i_1]...[i_n]. > >> > >>I think I wrote earlier about this shorthand ... > >> > >>I found the following problem: > >> > >>ARRAY OF ARRAY OF Something > >> > >>is syntactically not quite a 2D-array since as it is written it suggests > >>that the sub-arrays may have different sizes. > > > >It never occurred to me that this syntax could suggest it could be a > >ragged array, probably because I was already familiar with the (fixed) > >array-of-array concept being truly 2D in Pascal and Modula2. > > I did not have problems in understanding the Modula-3 report, instead I > consider it a flaw in the syntax and it has practical consequences. Why can > I choose in ARRAY OF ARRAY only the size of the outer array freely and the > sizes of the inner arrays are constrained? Where is the composability of > type constructors? And what is the size of the inner arrays if there are no > inner arrays? What else would be the type of a ragged array, if not ARRAY OF > ARRAY OF T? > > In Haskell "Array Int (Array Int a)" would be actually a ragged array (in > Haskell all objects are actually pointers to objects) and a rectangular > 2D-array would have the type "Array (Int,Int) a". Algol 68 has n-dimensional arrays, for fixed n. That is, the number of subscripts is fixed by the program at compile time. THey are rectangular. The size of arrays are fixed at allocation time. They are not part of the type of the array. It is possible to have zero by n arrays, and n by zero arrays. There is nothing preventing an array from having other arrays as components. Those other arrays will have their own rectangular storage space elsewhere. Arrays can be declared to be flexible, in which case the flexibility is part of the array type and the actual array can change its size at run time.. There's an obscure corner of the semantics involving flexible arrays whose elements are inflexible arrays. The language definition describes a ghost element to remember the size of the inner arrays. It's not clear to me that this is anything but pedantry. -- hendrik