[M3devel] another longint variant

[Jay K]

[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'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;

 

 

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.

 

 

For assignability I think your change does work but mine was less wordy

and maybe more general;

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;

This makes enums <=> longint, integer subranges <=> longint, etc;

 

 

 

 - Jay

 


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




It should suffice for assignability...


On 9 Jan 2010, at 14:33, Jay K wrote:

I don't believe that suffices but I can check again.
 
 - 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/20100109/067315ea/attachment-0002.html>