[M3devel] index array by longint?

[Tony Hosking]

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/20100109/c1e26ed4/attachment-0002.html>