[M3devel] another longint variant

[Tony Hosking]

On 9 Jan 2010, at 19:31, Jay K wrote:

> 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?

Yes, clarity is important.

> Or too verbose?

Verbosity is sometimes valuable.  It spells things out.

> 
>  - 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/20100109/5f1ae41d/attachment-0002.html>