[M3devel] another longint variant

Sun Jan 10 01:31:31 CET 2010

I noticed unary plus doesn't seem to be valid for LONGINT.
That is fixed among my other diffs.

I understand it matters little to take this "algorithmic" approach to determining
if an AddExpr is valid. We haven't yet agreed it will even change from current,
though I kind of think it would. Again, if I can assign LONGINT to INTEGER,
and then add it, or vice versa, why not just allow the direct addition?
Force the programmer through hoops so the code is much clearer?
Or too verbose?

 - Jay

From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 19:21:38 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] another longint variant

On 9 Jan 2010, at 19:15, Jay K wrote:Also, I would propose that AddExpr etc. could check if the types are assignable, and then allow the add, etc;
However there is still the matter of chosing the return type, so maybe have to just do the complete check in each
FooExpr.m3 file, not just delegate to IsAssignable;
Possibly the return type could be "calculated", like as being the "larger" type in most cases,
the "smaller" in a few. That way, e.g. if we add a third yet larger integer type, the code would just work;

It is a bit of a stretch that we've even added LONGINT.  So, don't get carried away thinking there'll be more.
I'm in the middle of fixing some bugs in the range checking that were introduced when I added support for LONGINT.   Its addition has turned out to be the source of some significant compiler bugs.

 - Jay

From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] another longint variant
Date: Sun, 10 Jan 2010 00:12:06 +0000

 > I believe Rodney said something like "mixed operations follow from assignability";
 > and from a language point of view, that may be true, just not from the point of view;

I meant to say, not from the language implementation point of view.

Again, if I can assign and then add, might as well just allow add?
Ditto assign and index, assign and multiply, etc.

 - Jay

From: jay.krell at cornell.edu
To: hosking at cs.purdue.edu
Date: Sun, 10 Jan 2010 00:05:23 +0000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] another longint variant

Sorry something wasn't clear.
If you just allow assignability, sprinkling ORD is sufficient, and must be done a lot, as presented in one of my diffs;
Annoying, voluminous, but should suffice.
I'll do it again if you need.

With mixed operations and assignability, the only change outside libm3 is
 changing the signatures of Length and Seek
 and the FOR change, though that's just because I didn't really finish
   the mixed operation change.

I just meant that assignability fix in the compiler doesn't suffice
  to actually enable mixed operations.

I believe Rodney said something like "mixed operations follow from assignability";
and from a language point of view, that may be true, just not from the point of view;

You know, if I can assign a LONGINT to an INTEGER, and then add it to an INTEGER;
what is the difference vs. just allowing direct addition?

VAR i1,i2:INTEGER;
       j1: LONGINT;

i1 := j1;
INC(i2, i1);

vs.
INC(i2, j1);

If the first is allowed, shouldn't the second?

 - Jay

From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 15:54:22 -0500
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] another longint variant

On 9 Jan 2010, at 15:17, Jay K wrote:[replacing periods with semicolons to avoid truncation..]

Right..I was going to say..as an overall change, like if we
want mixed operations, it really doesn't suffice;
Many of my m3front changes were in direct response
to compilation errors and fixed them;

I'd like precise examples.
 I'm sure as well that just allowing assignability doesn't make the rd/wr
change particuarly small/smooth. You need mixed operations,
indexing, new, or else sprinkle ORD around;

I'm not sure I see why sprinkling ORD is insufficient...  again, precise examples.
 There's a particular characteristic I should point out in the rd/wr code;
Maybe rd/wr should be modified..but it probably can't;
In particular, my understanding of rd/wr is that the maintain two
"numbers" (integer or longint, depending on how everything is resolved);
These numbers indicate the file offset that is at the start of the buffer
and at the end of the buffer. In a new world they need to be LONGINT;
However their "span", their difference, describes an
in-memory buffer size. Therefore their difference is always INTEGER
or CARDINAL, not LONGINT. It'd be super cool, but probably not
possible, if the language let you declare this somehow.
THEN mixed operations and such wouldn't be needed,
if the compiler new that subtracting these two integers
yielded an INTEGER, and possibly inserted checks of that;
But this is probably just a lazy user view and not realistic
for the language.

That would be tricky...
 For assignability I think your change does work but mine was less wordy
and maybe more general;

No, yours breaks assignabilty from subrange to INTEGER/LONGINT.
The preexisting code allowed I believe any non-LONGINT ordinal
type to be assigned to any non-LONGINT ordinal type if there
are any overlapping values. Specifically really,
non-ordinal types with same base type and anyoverlap.
I removed the base type check;

That's what broke it.
This makes enums <=> longint, integer subranges <=> longint, etc;

Can I convince you to work things up with my trivial change?
I really want to see the impact of not allowing mixed arithmetic while having assignability.

 - Jay

Subject: Re: [M3devel] another longint variant
From: hosking at cs.purdue.edu
Date: Sat, 9 Jan 2010 13:30:55 -0500
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu

Jay, what are the implications of just having assignability rather than mixed arithmetic?  Can you work through that change?   My preference right now is to allow assignability (range-checked, of course) but not mixed arithmetic.  The simple little patch I sent you for Type.IsAssignable on ordinals should allow you to test things. As far as I can tell, that will simply work...
On 9 Jan 2010, at 05:22, Jay K wrote:[attached]
In this variant, the compiler has been made
 "maximally lenient" and the rd/wr changes are minimized.

Specifically:
  compiler allows assignment either way and various math
  operations, including NEW array and array subscript.
  mixing in FOR loops is missing (FOR i := INTEGER TO LONGINT or LONGINT TO INTEGER)

  rd/wr changes outside libm3 are only changing
   the signatures of Seek and Length
   pretty minimal, and hard to imagine they could be smaller,
    though actually they could..well..the need to fix existing
    rd/wr could be eliminated/delayed
    rd/wr could introduce SeekL, LengthL which by default
    call Seek/Length, and then rd/wr could gradually convert,
    and not gain 4GB capability until then

  no VAL or ORD needed

  some rd/wr implementations might be artificially limited
  to 4G simply because they don't chane some INTEGER to LONGINT;
  "anything compiles"

  some of the compiler changes are probably slightly off or incomplete
   including a need to insert the checks for LONGINT => INTEGER

<dif3.txt>

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