[M3devel] another longint variant

[Tony Hosking]

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