[M3devel] index array by longint?

Sun Jan 10 08:58:56 CET 2010

It is easy to frame in terms of assignability?

  a + b is legal if a is assignable to b, or b is assignable to a  

If you don't allow INTEGER := LONGINT,

then you can say, like:

a + b is legal if a is assignable to b or b is assignable a (or both);

if a and b are of different type, and only one is assignable to the

other, then the result type is that of the assignable-to type.

If INTEGER := LONGINT, then I'm not sure how to formally

define the result. Something informal:

a + b is legal if a or b is assignable to the other

the result type is the "larger" or "wider" type -- whatever that means;

However, I think there is an easy enough to define set of rules.

It varies for each operator though.

Basically, first, the notion of "larger" or "wider" isn't

all that unscientific. It needs a little honing though;

a + b is legal if a is assignable to b or b is assignable to a (or both).

If a and b are of the same type, that is the result type.

If a and b are of different types, but one of their types can

  represent without loss all the values of the other type,

  then that is the result type.

If a and b are of different types, and neither type can represent

  all of the values of the other type, then the result type is

   INTEGER if it can represent all the members of the types of a and b,

   else LONGINT.

The result type is stated in terms of the input types.

Not in terms of the output range.

This is a general fact of life with addition anyway.

The result of adding two integers is an integer, even though integer

cannot hold the output range.

I have a strong suspicion that we would be more satisified

with our rules if overflow checking was present.

Heck, maybe we'd have something wierd where INTEGER + INTEGER

actually yielded LONGINT, but then LONGINT is assignable to INTEGER?

The overflow check would actually be at the assignment/narrowing?

Heck, it's not like double precision arithmetic is even so expensive?

What do you mean by, reworded, "the operators aren't typed"

- Jay

From: hosking at cs.purdue.edu
Date: Sun, 10 Jan 2010 02:37:45 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] index array by longint?

Try to frame this in terms of assignability...

If the operators themselves were typed then there would be no problem.

But when they aren't we get into a real mess trying to remember what the promotion rules are.

On 10 Jan 2010, at 01:11, Jay K wrote:

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/16a68025/attachment-0002.html>