[M3devel] latest longint file size diffs

[Rodney M. Bates]

Jay K wrote:
> I'll admit to being a little unsure.
> 
> 
> I do hope the rd/wr change can be done with a small diff, maybe nothing 
> outside libm3.
> 
> 
> You might classify me more as a lazy user than a language designing deep 
> thinker.
> 
> 
> But I'm curious even about your assertion.
> 
> 
> Let's pretend INTEGER is 8 bits and LONGINT is 16 bits, ok?
> It is easier for me.
> 
> 
>   INTEGER max := 16_7F;  
>   INTEGER first := 16_80;
>   INTEGER p1 := max + 1;
>   LONGINT p1L := max + 1L;
> 
> 
> So, what happens if we compare p1 with first and p1L with first?
> Again remember INTEGER is 8 bits, LONGINT is 16 bits.
> 
> p1 will be -128, 0x80.
> p1L will be 128, 0x0080.
> 
> 
> What then happens when you compare 0x0080 to 0x80?
> Are they equal (truncate both to INTEGER and compare), unequal (sign 
> extend to LONGINT and compare), or you get an exception (upon narrowing 
> the LONGINT to INTEGER and it doesn't fit)?

Whether mixed comparison is allowed or an explicit conversion is coded
before comparing, the representation conversion of the value of p1 to
LONGINT will do a sign extension, because INTEGER and LONGINT are
both signed.  Or rather, all the builtin operations apply signed
interpretation.

If instead, you converted p1 to LONGINT via the Long.FromWord I proposed,
then it would be a zero extension.  This can only be done explicitly.

The comparison would always be done in 16 bits, unless you explicitly
converted the LONGINT operand.down to 8 first.

> 
> 
> And heck, shouldn't max + 1 already throw an exception?

This is a separate issue.  I have always been very skeptical about silently
ignoring overflow.  But all the questions about INTEGER and LONGINT really
hinge only on the question of when does an overflow occur, not what happens
when it does.

> 
> 
>  - Jay
> 
> 
> ------------------------------------------------------------------------
> From: hosking at cs.purdue.edu
> Date: Sat, 9 Jan 2010 01:03:08 -0500
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] latest longint file size diffs
> 
> On 9 Jan 2010, at 00:50, Jay K wrote:
> 
>     I don't know the precedence but agreed:
> 
> 
>     >  OR (IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL))
>     >  OR (IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL)))
> 
>     I was being sort of lazy.
>     I've never touched the front end and it was critical I be able to make
>     a small change and see fairly precisely the expected change, even
>     if I didn't get all cases.
> 
>     This is I'm sure why I had to add some VAL/ORD uses, to convert "UINT32"
>     in the Win32 code to INTEGER or LONGINT.
> 
> 
> Yes, that would be why.
> 
>     Also, I really think mixed arithmetic is ok.
> 
> 
> But are you ok with:
> 
> (LAST(INTEGER) + 1) = FIRST(INTEGER)
> 
> while
> 
> (LAST(INTEGER) + 1L) # FIRST(INTEGER)
> 
> ?
> 
> I find such things to be difficult to explain to the novice programmer. 
>  Modula-3 was designed using the "principle of least surprise" and I 
> frankly find the above to be very surprising!
> 
> 
>      - Jay
> 
> 
>     >  From: hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>
>     >  Date: Sat, 9 Jan 2010 00:37:42 -0500
>     >  To: jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>
>     >  CC: m3devel at elegosoft.com <mailto:m3devel at elegosoft.com>
>     >  Subject: Re: [M3devel] latest longint file size diffs
>     > 
>     >  Looking at your code, I think the assignability test for ordinals
>     should be more like:
>     > 
>     >  IF (IsEqual (Base(a), Base(b), NIL)
>     >  OR IsEqual (Base(a), Int.T, NIL) AND IsEqual (Base(b), LInt.T, NIL)
>     >  OR IsEqual (Base(a), LInt.T, NIL) AND IsEqual (Base(b), Int.T, NIL))
>     >  AND GetBounds (a, min_a, max_a)
>     >  AND GetBounds (b, min_b, max_b) THEN
>     >  (* check for a non-empty intersection *)
>     >  min := min_a; IF TInt.LT (min, min_b) THEN min := min_b; END;
>     >  max := max_a; IF TInt.LT (max_b, max) THEN max := max_b; END;
>     >  RETURN TInt.LE (min, max);
>     >  ELSE
>     >  RETURN FALSE;
>     >  END;
>     > 
>     >  That way CARDINAL and other subranges fall right out.
>     > 
>     >  Antony Hosking | Associate Professor | Computer Science | Purdue
>     University
>     >  305 N. University Street | West Lafayette | IN 47907 | USA
>     >  Office +1 765 494 6001 | Mobile +1 765 427 5484
>     > 
>     > 
>     > 
>     > 
>     >  On 8 Jan 2010, at 06:13, Jay K wrote:
>     > 
>     >  > Attached is my latest work here.
>     >  > With the compiler changes (in the diff), I was able to
>     >  > elminate most uses of VAL(expr, LONGINT).
>     >  > There's something slightly off such that I had
>     >  > to add a very small number, like two.
>     >  > 
>     >  > 
>     >  > The compiler change is newer than earlier.
>     >  > For example you can now assign CARDINAL to LONGINT.
>     >  > I didn't do it, but you should also be able to add/subtract/etc.
>     >  > mixing CARDINAL and LONGINT.
>     >  > 
>     >  > 
>     >  > FOR statements also don't allow the level of mixing
>     >  > that they should.
>     >  > 
>     >  > 
>     >  > I'm hoping to get agreement soon just from the diffs
>     >  > but if necessary I'll look how to create a branch.
>     >  > My general worry about branches is developers just
>     >  > go off on their own in a branch and it's impossible to
>     >  > get anyone to look at it, they are busy enough with one branch,
>     >  > let alone multiple..
>     >  > 
>     >  > 
>     >  > - Jay
>     >  > <dif8.txt>
>     > 
> 
>