[M3devel] mixing INTEGER and LONGINT?

[Jay K]

 > The question remains: is LONGINT necessary or simply a kludge better satisfied by arbitrary precision arithmetic like BigInteger.T?


Two of us addressed this.

The answer is not technically/scientifically pleasing.
The answer is simply that in-fix operators are more convenient and libraries are not.

Obviously the general clean answer is either:

   operator overloading on user defined types, making the library convenient 

   or maybe a language feature for fixed but arbitrary precision integers

    e.g. 

     int1024 = BITS 1024 for INTEGER

     or uint1024 = BITS 1024 for [0..Word.LShift(1, 1024)]

     or uint1024 = [0..Word.LShift(1, 1024)]

 

 

and the compiler would be compelled to generate code for any precision.

 

 

These are both more work.

LONGINT is indeed a special case.

C compilers all provide it "long long" or "__int64".

File sizes are indeed probably the typical use case for C?

But also things like InterlockedCompareExchange64 of some "packed" format.

 

Personally I would gladly accept

 FileSize = [0..Word.LShift(1, 63 or 64)];

 

 

even so...the compiler/language feature could (initially) limit the "bits" to 64, but

still implement via this more general syntax and not some new special type/keyword.

 

 

This is the question floating around: maybe there are just integers of varying size/range.

 

 

Maybe the compiler can notice if the size is <= or > a natural size?

 

Mixed arithmetic would be possible among arbitrary pairs of sizes and have a simple

formula for the result. Assuming "silent wraparound", addition would just pick the larger of the two.

But then, what if I assign to an even larger type? Hm.

Then you want addition of n and m to produce max(n, m) + 1, and such.

Perhaps there is some rule..you know..checked narrowing..?

And the checks can be omitted if the assignment is to a larger type?

e.g.

LONGINT := INTEGER + INTEGER => no overflow check

LONGINT := LONGINT + LONGINT => overflow check

int1024 := LONGINT + LONGINT => no overflow check

?

 

 

In reality I think no code would use the wider := narrow + narrow.

But it seems technically reasonable.

 

 

In reality code either wants the overflow check, or a type that expands its precision as needed.

("bignum", etc.)

 

 

 - Jay

 
> From: hosking at cs.purdue.edu
> Date: Fri, 8 Jan 2010 15:51:13 -0500
> To: rodney_bates at lcwb.coop
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] mixing INTEGER and LONGINT?
> 
> Once more summarising the discussion so far.
> 
> *If* we accept that LONGINT should stay then I agree we should implement Rodney's proposal (the current implementation + assignability between INTEGER and LONGINT + mixed arithmetic).
> 
> The question remains: is LONGINT necessary or simply a kludge better satisfied by arbitrary precision arithmetic like BigInteger.T?
> 
> On 8 Jan 2010, at 14:42, Rodney M. Bates wrote:
> 
> > 
> > 
> > Mika Nystrom wrote:
> >> Tony Hosking writes:
> >> ...
> >>> A type T is assignable to a type U if:
> >>> 
> >>> =95 T <: U, or
> >>> =95 U <: T and T is an array or a reference type other than =
> >>> ADDRESS (This restriction is lifted in unsafe modules.), or
> >>> =95 T and U are ordinal types with at least one member in =
> >>> common.
> >>> 
> >>> This suggests that we don't really need to say that INTEGER <: LONGINT.
> >>> 
> >>> We can simply rely on the third clause regarding their both being =
> >>> ordinal types with at least one member in common. Then assignment =
> >>> simply needs to test that the values are in range.
> >>> 
> >> Are you sure about this for INTEGER and LONGINT? I.e., are 0 and 0L
> >> the same "member"?
> >> By a similar argument, you could make REAL and LONGREAL assignable.
> >> Are 0.0d0 and 0.0e0 the same "thing"? (On almost all machines they have
> >> the same bit patterns, same as 0 and 0L for that matter, and I can add
> >> that the way you do single-precision floating point on Alpha is by zeroing
> >> a big chunk in the middle of your double-precision fp registers...)
> >> I think I am with you on removing LONGINT from the language. The proper
> >> way of handling file sizes (or anything else that might be a bigger number
> >> than a machine word) is through abstraction. I have a suspicion that it's
> >> probably a severe micro-optimization to worry about the efficiency of
> >> operations on file sizes. The thought that someone is adding automatic
> >> type conversion to Modula-3, a la C, makes me feel slightly sick to
> >> my stomach...
> > 
> > I agree, I hate the horrible complexities of implicit type conversions
> > in other languages. But this doesn't have to be done by automatic type
> > conversion, just another instance of Modula-3's existing superior concept of
> > assignability between non-disjoint types.
> > 
> >> I confess that my position is influenced by the fact that I have written
> >> many programs that generate Modula-3 code as an "intermediate language".
> >> I really really really need M3 to be easy to understand to get this to
> >> work well. Also being able to parse interfaces and know precisely what
> >> they mean is important to me. If the rules start getting sloppy.. that
> >> would really upset me. On the other hand this means that if I'm faced
> >> with a problem that doesn't really fit into M3 well, say, working in
> >> arithmetic mod 2^(wordsize), my first instinct is not to demand changes
> >> to the language definition but to write a code generator that takes
> >> appropriate infix (or maybe more likely prefix) code and turns it into
> >> the appropriate calls through the Word interface. It's a pain, yes, but in the long run that's the right way, because you can do so much
> >> more with that approach than just unsigned integers.
> >> Mika
> > 
> > In my original proposal, I said:
> > -------------------------------------------------------------------------
> > This proposal satisfies (I believe) the following principles:
> > 
> > The static correctness and type analysis of existing code written to
> > the current language definition will not change with the new
> > definition. This also implies that the new language definition will
> > not introduce new type mismatches that would make existing pickles
> > unreadable.
> > 
> > The runtime semantics and time and space efficiency of existing code
> > written to the current language definition will also not change with
> > the new definition, if the native word size of the implementation does
> > not change. Of course, porting existing code to an implementation
> > with different native word size can change the runtime semantics by
> > changing the supported value range, with or without language change.
> > 
> > The static type analysis of programs written to the modified language
> > definition will be independent of the implementation, particularly, of
> > the native word size. This prevents inadvertently writing code that
> > is highly nonportable among different native word sizes.
> > 
> > The new, not-necessarily-native integer type does not extend to
> > certain existing uses of INTEGER and CARDINAL that are of unlikely
> > utility and would add complexity.
> > 
> > 
> > -------------------------------------------------------------------------
> > 
> > I still believe we can do these things, and also that the changes
> > to the language are not too drastic. They are mostly just more
> > instances of existing concepts.
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100108/0ec29705/attachment-0002.html>