half and quad

[Paul Anderson]

Janice Caron Wrote:

> On 10/11/07, Olifant <olifant at gmail.com> wrote:
> > The keyword "cent" is reserved for 128-bit integers. Could "half" and "quad" be reserved for respectively 16-bit and 128-bit floating point numbers?
> 
> I've always thought the names we have for built-in types are (mostly)
> horrible. Consider "short", "int" and "long". Seems fine on a 32 bit
> processor, but in the far, far future, when even longs are considered
> tiny, those words would all be wrong. "cent". - why cent? Cent means
> 100. So if you use "cent" for a 128 bit integer, what do you use for a
> 256 bit integer? And what does the "d" stand for in "dchar"? And as
> for "quad" and "half" - it's not intuitively obvious that these are
> floating point.
> 
> I'd vote for more obvious names any day:
> int8, int16, int32, int64, int128...
> uint8, uint16, uint32, uint64, uint128...
> real16, real32, real64, real80, real128...
> 
> with "int", "uint" and "real" being aliases for whatever type is
> "machine native".

I like this naming scheme, although I have a little trouble with the size of int being machine dependent. (Isn't there an old language that did that? ;-))

Of course, we'd have to accommodate all the code out there already using long and short. But new type names for new types should be okay and I like real16 and real128 better than half and quad.

I'm also dubious that long will ever be tiny -- the use cases for very long integers, while important, aren't that numerous. There's a point of diminishing returns on processor word size, at least for general purpose machines, that may well be 64 bits, IMHO.

Paul

(Now if I can just avoid posting this twice!)

I