[M3devel] Oops, forgot to ask

[Tony Hosking]

On 16 Dec 2009, at 19:52, Jay K wrote:

> "0..LAST(LONGINT)" having varying meaning...like when INTEGER is > 64 bits, then LONGINT=INTEGER, and we anticipate 128 bit INTEGER?
>  
>  
> See..LONGINT is only useful in this brief period where we still have 32bit INTEGER.
> (Actually it would have been useful long ago.)

LONGINT could be 128 bits for all its definition cares.  It is just something usually (not always) bigger than an INTEGER.

>  I really think "long" is a dumb name..
> There should be INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64, and unsigned and signed integers the same size of a pointer, possibly called INT and UINT, or size_t and ptrdiff_t..

Now these are dumb names because they wire in the size of the value.

In Modula-3 INTEGER is a natural (i.e., word-size) value.

>  
>  
>  - Jay
> 
>  
> > Date: Wed, 16 Dec 2009 16:56:55 -0600
> > From: rodney_bates at lcwb.coop
> > To: m3devel at elegosoft.com
> > Subject: Re: [M3devel] Oops, forgot to ask
> > 
> > Tony Hosking wrote:
> > > On 16 Dec 2009, at 15:48, Peter Eiserloh wrote:
> > >
> > > 
> > >> Hi Gang,
> > >>
> > >> 0 - CARDINALs are an integral type defined by the language
> > >> spec to be from 0 (zero) to MAXINT (not MAXCARD). Recently,
> > >> a change was made to CM3 to extend the language it recognizes
> > >> beyond the original language spec (SPWM3), now CM3 understands
> > >> a LONGINT. 
> > >>
> > >> Was there a corresponding LONGCARD defined?
> > >> 
> > >
> > > No. But you can write:
> > >
> > > [0L..LAST(LONGINT)]
> > >
> > > just as
> > >
> > > CARDINAL=[0..LAST(INTEGER)]
> > > 
> > Actually, the line above was once true, long long ago, when dinosaurs
> > roamed unfettered. CARDINAL was changed to be "just like"
> > (but not equal to) [0..LAST(INTEGER)]. This would have been
> > maybe early 1990s. 
> > 
> > It took me years to figure out what this actually meant, and more
> > years to figure out why, but I believe I now know. CARDINAL is not an
> > equal type to [0..LAST(INTEGER)], but otherwise has all the same
> > properties. This makes the two mutually assignable, which is close
> > enough to equal to not matter in most contexts. The exact consequences
> > follow from other language rules. 
> > 
> > The motivation is this: [0..LAST(INTEGER)] on a 32-bit machine is not
> > equal to [0..LAST(INTEGER)] on a 64-bit machine (or any combination of
> > machines with different values of LAST(INTEGER)), because the numeric
> > value of LAST(INTEGER) is part of the expanded type. The one place this
> > matters is if you use pickles to transfer data between machines of different
> > word sizes. If the type is [0..LAST(INTEGER)], the type signature (a hash
> > of the complete, expanded type definition) is different on the two machines,
> > and values of or containing this type cannot be transferred. Exact type
> > signature matches are used in pickles to find corresponding types when
> > reading. 
> > 
> > But pickles handle different sized INTEGER values fine, expanding/shortening
> > as needed. Being a leaf in a type definition, INTEGER is always the same
> > type on any machine. So CARDINAL was changed to be its own unique
> > type too, so it would be possible also to transfer CARDINAL values in 
> > pickles
> > between different word sizes. 
> > 
> > So, we really should have a LONGCARD, parallel to CARDINAL.
> > 
> > Note that this also affects network objects, which use pickles to transfer
> > values of the objects.
> > 
> > 
> > 
> > >
> > > 
> > >> Can is use all 64-bits, or is it restricted to 63, like
> > >> the CARDINAL is only 31-bits.
> > >> 
> > >
> > > 63 bits, since its underlying base type is LONGINT.
> > >
> > >
> > > 
> > >>
> > >>
> > >>
> > >> +--------------------------------------------------------+
> > >> | Peter P. Eiserloh |
> > >> +--------------------------------------------------------+
> > >>
> > >>
> > >>
> > >> 
> > >
> > >
> > > 
> > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091216/d96a5c02/attachment-0002.html>