[M3devel] Oops, forgot to ask

[Jay K]

"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.)

 

 

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..

 

 

 - 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/20091217/cb0a9a4b/attachment-0002.html>