[M3devel] INTEGER

[Mika Nystrom]

My "proposal" would be TEXT-like bignums.  Subranges would have to be
based on LONGINT constants.  Decree that they are instances of a particular
GENERIC INTERFACE maybe.  Hrmmm...

TYPE Range = [ 1L .. 1000L*1000L*1000L*1000L ];

equivalent to

REVEAL LONGINT <: ROOT;

TYPE LongInt.T = LONGINT;

GENERIC INTERFACE LongIntRange(R);

TYPE T = LONGINT BRANDED LongInt.ToText(R.Low) & "_"  & LongInt.ToText(R.High) OBJECT END;

END LongIntRange.

INTERFACE RR; CONST Low = 1L; High = 1000L*1000L*1000L*1000L; END RR.

INTERFACE RRType = LongIntRange(RR) END RRType.

TYPE Range = RRType.T;

or somesuch... hrmph too complicated?  It looks a lot like TEXT still.  I just
introduced a new function that the compiler needs to know: LongInt.ToText.
And a fake interface.  Ho hum, yes complicated.  But it looks like a pretty
normal Modula-3 type after these gyrations...

     Mika

Tony Hosking writes:
>But this is bizarre.  What type does an element of a subrange of LONGINT =
>have if not LONGINT?  If the subrange has a base type of INTEGER then we =
>need a mapping between the elements of the subrange and the base INTEGER =
>values.  But then, values of the LONGINT subrange don't have the same =
>representation as their INTEGER counterpart.
>
>All very odd.
>
>On 21 Apr 2010, at 14:56, hendrik at topoi.pooq.com wrote:
>
>> On Wed, Apr 21, 2010 at 09:55:29AM -0500, Rodney M. Bates wrote:
>>>=20
>>>=20
>>> Mika Nystrom wrote:
>>>> Tony Hosking writes:
>>>>> On 20 Apr 2010, at 13:12, Mika Nystrom wrote:
>>>> ...
>>>>>> easy access to the hardware in their own machines, not really so =
>that =3D
>>>>> IBM
>>>>>> programmers could have an extra format for VAX compatibility.  =
>Note =3D
>>>>> that
>>>>>> I don't believe that it was intended that EXTENDED would be =
>emulated =3D
>>>>> by
>>>>>> the compiler either: the point was really to give programmers =
>access =3D
>>>>> to
>>>>>> the formats provided efficiently by their hardware.
>>>>> In the current implementation EXTENDED=3D3DLONGREAL.
>>>>=20
>>>> Ok, but EXTENDED is still something that is efficiently provided by
>>>> my hardware.  Not something efficiently provided by someone else's
>>>> hardware!
>>>>=20
>>>>>> 4. I still haven't seen any really convincing use cases.  What's =
>it =3D
>>>>> for?
>>>>>> The lack of LONGINT was an obstacle to what, precisely?
>>>>> I think the only one we have is file sizes...
>>>>>=20
>>>>>> 5. Finally, is it the intention that LONGINT be fixed at 64 bits
>>>>>> forevermore?  (See point 2.)  This seems to completely fly in the =
>face
>>>>>> of M3's philosophy.  (See Hendrik's arguments.)
>>>>> The only constraint imposed is BITSIZE(LONGINT) >=3D3D =
>BITSIZE(INTEGER).
>>>>=20
>>>> I am not so sure here.
>>>>=20
>>>> Rodney's argument has in fact convinced me that the current version =
>of
>>>> LONGINT is wrong and perhaps evil.  It should either go away =
>completely
>>>> or be replaced by Hendrik's suggestion.
>>>>=20
>>>> Here's why.  The argument is that if I have an N-bit machine, for =
>N<M,
>>>> out there in the world there is an M-bit machine that for some =
>reason
>>>> matters a great deal to me.  For some reason I need to be able to =
>write
>>>> code that manipulates M-bit integers---because of the existence of =
>this
>>>> M-bit machine (or machines)! =20
>>>=20
>>> It has never been motivated by the existence of machines with various =
>native
>>> arithmetic sizes.  It is about problems that need big value ranges to =
>work.
>>>=20
>>> Its also about making it convenient to write portable code that =
>solves
>>> them. (Well, that part does have to do with the machines that exist.)
>>> And making the type checking, etc. not change on the different =
>machines.
>>> And using the most efficient arithmetic consistent with correct =
>answers.
>>>=20
>>> Normally we're dealing with the situation
>>>> that N=3D32 and M=3D64.)  So we introduce an M-bit LONGINT.  Now it =
>stands to
>>>> reason that if the M-bit machine (which I do not own and upon which =
>my
>>>> program does not run) is important to me, it is also important to =
>other
>>>> Modula-3 programmers.  Hence all other implementations of Modula-3 =
>will
>>>> *also* provide M-bit integers. =20
>>>>=20
>>>> The M-bit machine of the previous paragraph is of course, in the =
>real
>>>> world, a machine with the 64-bit version of the Intel x86 =
>instruction set,
>>>> "amd64".  How long is it from here to the point where we have =
>programmers
>>>> who write code that depends on the fact that M=3D64, always?
>>>=20
>>> LONGINT presents the same opportunity/invitation/temptation to
>>> write code that make such assumptions as does INTEGER, or for that =
>matter,
>>> REFANY, or gobs of other things in the original language.  So LONGINT =
>is
>>> just as evil as INTEGER.
>>=20
>> Which is why I'd allow only subranges of LONGINT to be mentioned in=20
>> programs.
>>=20
>> -- hendrik
>>=20
>>>=20
>>>>=20
>>>>    Mika
>>>>=20
>>>>=20