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: <CAEy6uxpP+RcUY-OOP2wVyj_5FwD6AnY1Ax=sPr9y9e3eucKBAw@mail.gmail.com>

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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20180301/bcdfd8be/attachment.html>

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: <CAEy6uxpP+RcUY-OOP2wVyj_5FwD6AnY1Ax=sPr9y9e3eucKBAw@mail.gmail.com>
References: <CAEy6uxpP+RcUY-OOP2wVyj_5FwD6AnY1Ax=sPr9y9e3eucKBAw@mail.gmail.com>
Message-ID: <e8543a06-03cd-1dce-2af5-2e18b9fd36b2@lcwb.coop>

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?

<rant>

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.

</rant>

-- 
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: <alpine.DEB.2.20.1803212051220.14206@sputnik>


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: <CAM3tuSEn5TffZ=jnRqKFLVkH12MK=+=keT8MNZcRab6ePduKmw@mail.gmail.com>

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 <rodney_bates at lcwb.coop>
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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20180324/21c8f23a/attachment-0001.html>

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: <alpine.DEB.2.20.1803212051220.14206@sputnik>
References: <84cdfcdd-eebc-e937-cb08-1f1d31ebe299@lcwb.coop>
 <alpine.DEB.2.20.1803212051220.14206@sputnik>
Message-ID: <a09e5449-17cc-5d1f-2318-af36e7611121@lcwb.coop>

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: <CAM3tuSEn5TffZ=jnRqKFLVkH12MK=+=keT8MNZcRab6ePduKmw@mail.gmail.com>
References: <6cb9a420-315e-cf31-f789-1c8cc86746c4@lcwb.coop>
 <02ab06b7-28cb-3b34-47ad-ec4b7c3665b4@lcwb.coop>
 <CAM3tuSEn5TffZ=jnRqKFLVkH12MK=+=keT8MNZcRab6ePduKmw@mail.gmail.com>
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 <rodney_bates at lcwb.coop <mailto:rodney_bates at lcwb.coop>> 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 <mailto: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 <mailto:rodney.m.bates at acm.org>
>
>     _______________________________________________
>     M3devel mailing list
>     M3devel at elegosoft.com <mailto: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

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>
 <CAM3tuSEn5TffZ=jnRqKFLVkH12MK=+=keT8MNZcRab6ePduKmw@mail.gmail.com>
 <01d462b5-37f6-061b-3c6f-ab6978bc9559@lcwb.coop>
Message-ID: <CAM3tuSFSrXQDqWU6rD0bKSg5DrGyZ6Ut3zGKmvwP-0BHkUwJBw@mail.gmail.com>

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 <rodney_bates at lcwb.coop>
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 <rodney_bates at lcwb.coop
>> <mailto:rodney_bates at lcwb.coop>> 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 <mailto: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 <mailto:rodney.m.bates at acm.org>
>>
>>     _______________________________________________
>>     M3devel mailing list
>>     M3devel at elegosoft.com <mailto: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: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20180324/3e2057e4/attachment.html>

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>
 <alpine.DEB.2.20.1803212051220.14206@sputnik>
 <6cb9a420-315e-cf31-f789-1c8cc86746c4@lcwb.coop>
Message-ID: <alpine.DEB.2.20.1803241755120.5332@sputnik>


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: <alpine.DEB.2.20.1803241755120.5332@sputnik>
References: <84cdfcdd-eebc-e937-cb08-1f1d31ebe299@lcwb.coop>
 <alpine.DEB.2.20.1803212051220.14206@sputnik>
 <6cb9a420-315e-cf31-f789-1c8cc86746c4@lcwb.coop>
 <alpine.DEB.2.20.1803241755120.5332@sputnik>
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