[M3devel] [Fwd: Re: A nonnative 64-bit language proposal]

[Darko]

On the other side of the ledger, the fact that the following  
overflows is pretty unpleasant:

CONST big = 2^32-1;
VAR i: LONGINT;
BEGIN i := big * big;


On 19/07/2007, at 11:35 PM, Darko wrote:

> I agree with you and I strongly agree with Tony's approach to the  
> implementation where the two integer types are not subtypes.
>
> The VAL usage would be a bit finicky given how often this would be  
> done in practice, something more concise (like INT and LONG) would  
> be better.
>
>
> On 19/07/2007, at 11:20 PM, Rodney M. Bates wrote:
>
>> In my original 64-bit proposal, I made INTEGER # LONGINT, and also  
>> the two
>> types have no subtype relation (which, I think is what Antony is  
>> saying).
>> It avoids having a lot of things happen implicitly from other  
>> rules in the
>> language.
>>
>> But then I added a separate rule that these two types and their  
>> subranges
>> are mutually assignable, subject to the existing assignability  
>> rules that
>> now apply to a type and its subranges. Namely the RHS value must  
>> be in the
>> range of the of the LHS type, which sometimes has to be checked at  
>> runtime.
>>
>> This allows assignment without explicit conversion, as well as  
>> many other
>> things, for example, VALUE parameter passing, that require  
>> assignability.
>> This is consistent with the existing rules for assignments involving
>> different subranges.
>>
>> For explicit conversions (which are probably needed somewhere anyway,
>> even if not in assignments), VAL(v,LONGINT) and VAL(v,INTEGER) fit
>> the existing language well.  For consistency, it seems good to allow
>> ORD(LongIntArg), which is an alternative conversion in one direction.
>> It may seem unnecessary, but it's not as useless as ORD(IntegerArg),
>> which we already have.  Actually, these extensions of VAL and ORD
>> fall out of the existing definitions, when LONGINT is an ordinal  
>> type.
>>
>> Darko wrote:
>>> I actually favour a implicit conversion, which for this  
>>> particular  case I think would be consistent with existing M3  
>>> behaviour.
>>> On 19/07/2007, at 10:26 PM, Tony Hosking wrote:
>>>> This is a good question.  I would assume that conversion must  
>>>> be  explicit to fit with the M3 philosophy.  It would make sense  
>>>> to  have a conversion operation that performs the appropriate  
>>>> range  check?  Any ideas for a name for the operation.
>>>>
>>>> On Jul 19, 2007, at 4:23 PM, Darko wrote:
>>>>
>>>>> Have I missed something or is there no way to assign between   
>>>>> INTEGER and LONGINT? Is there an explicit conversion function  
>>>>> that  I've overlooked? Would assignment be so bad here since  
>>>>> there would  be an implicit range check, much like when you  
>>>>> assign between two  overlapping subranges? In a sense these two  
>>>>> types are integer  subranges of an abstract integer type  
>>>>> containing all integers.
>>
>> -- 
>> -------------------------------------------------------------
>> Rodney M. Bates, retired assistant professor
>> Dept. of Computer Science, Wichita State University
>> Wichita, KS 67260-0083
>> 316-978-3922
>> rodney.bates at wichita.edu
>