[M3devel] index array by longint?

[Jay K]

I don't think there is madness here.
I believe the half range of CARDINAL helps avoid it.
A confusing point in C is comparison that includes conversion
is magnitude or sign preserving -- comparing int and unsigned.

Back to Modula-3:

a := b;
c := a + d;

vs.

c := b + d;


are different?
Isn't that strange?


Compare with
a : = b;
c := d[a];

and

c := d[b];

we have decided they are the same, among others.


There's something about "kinda sorta transitive" here.
Or, like, "why should I have to move values through temporaries in some
cases but not others?"

 - Jay



Subject: Re: [M3devel] index array by longint?
From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 23:46:39 -0500
CC: rodney_bates at lcwb.coop; m3devel at elegosoft.com
To: jay.krell at cornell.edu



I have a feeling that the mixed arithmetic option is losing favor.  It is a slippery slope to C madness.
On 9 Jan 2010, at 23:42, Jay K wrote:There are more cases:

=, #, <, >, IN, etc. have this same "you can mix
if they are assignable" rule.

http://www.cs.purdue.edu/homes/hosking/m3/reference/relations.html

     infix    =, #  (x, y: Any): BOOLEAN
The operator = returns TRUE if x and y are equal. The operator # returns TRUE if x and y are not equal. It is a static error if the type of x is not assignable to the type of y or vice versa.
...


Other places demand equal types:
http://www.cs.purdue.edu/homes/hosking/m3/reference/arithmetic.html

inc/dec sound looser:
http://www.cs.purdue.edu/homes/hosking/m3/reference/incdec.html


I still think mixed operations are reasonable and the result types not so surprising.
a := b;

vs. a := b + c;

The first is clear even if and b have different types, but the second is not, if b and c have different types?
They seem pretty equally clear/unclear to me..


 - Jay


From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 23:22:44 -0500
To: rodney_bates at lcwb.coop
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] index array by longint?

That's very nice!  I like it.  I think we can use it....Right now I am tracking bugs in range checking.  Some were introduced by my LONGINT changes (sigh!) but others appear to have been around a while before that.
For example:
VAR s: CARDINAL := LAST(INTEGER);BEGIN INC(s) END;
did not result in a run-time error.  I think I have fixed that now (commit to come).
But, even worse:
VAR s: CARDINAL := LAST(INTEGER);BEGIN WITH x = s DO x := VAL(ORD(x) + 1, CARDINAL) END END;
also does not give a run-time error.
The result is that you can store FIRST(INTEGER) in a CARDINAL.  Yikes!
On 9 Jan 2010, at 21:54, Rodney M. Bates wrote:When writing my original proposal, I agonized at length over whether
to allow (subranges of) LONGINT to be the index type of an array type.  In the
end, I decided that gave a poor ratio of practical benefit to language
and implementation complexity.

However, note, from 2.6.3, "Designators,

"a[i]
   denotes the (i + 1 - FIRST(a))-th element of the array a. The expression a[i] is a
   designator if a is, and is writable if a is. The expression i must be assignable
--------------------------------------------------------------------------^
   to the index type of a. The type of a[i] is the element type of a."

So, by existing rules about assignability, when referring to an element of an
array, the subscript expression could have base type LONGINT, and would just
be "assigned" in the usual way to the index type, a subrange of INTEGER.
This is one of the dozen or so places assignability is used in the language.



Jay K wrote:
Index array by longint?
With runtime check that it is <= LAST(INTEGER)?
 Or really, with runtime bounds check against the array size.
Seems reasonable?
Aids the rd/wr change.
A little bit of pain to implement..unless INTEGER and LONGINT have a common base...
  - Jay


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100110/13e75042/attachment-0002.html>