[M3devel] another longint variant

Tony Hosking hosking at cs.purdue.edu
Sun Jan 10 01:21:38 CET 2010


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/20100109/2db04789/attachment-0002.html>


More information about the M3devel mailing list