[M3devel] another longint variant

[Jay K]

 > 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/661f6ffb/attachment-0002.html>