> IMO, the Windows type naming convention is, when not taken further with those P... and FP... types is rather okay. It has "byte", "word", "dword", and "qword" (cont. would be "hword"), all are signed, and unsigned variations exist. In the beginning i found anything beyond "word" pretty awful though.

Word is a dangerous `word`; not all architectures use the win32/x86 16 bit
word convention;
on the Arm CPU's the types are
byte (as ever 8 bits)
word ( 32 bits )
halfword( 16bits )
doubleword( 64 bits )

there is an Arm linux (I know of one machine the strong arm netwinders) and Arm CE, and I see Palm are moving from 68k to Arm based arch in their PDA's

getting the language architecturally neutral to me would be a good thing

Walter wrote:
> "Burton Radons" <loth@users.sourceforge.net> wrote in message
> news:b0jaqq$2gro$1@digitaldaemon.com...
> 
>>complex hasn't been used enough yet.  Adding to it violates your rule of
>>never adding a feature that isn't actually necessary.
> 
> Complex and imaginary are part of standard C99.

The C pre-processor is part of standard C99.

> ifloat = imaginary float
> idouble = imaginary double
> ireal = imaginary real

I wonder about these. How often does one work with in the pure imaginary numbers for more than a single operation or two? I would get by just fine with just the other 6 (pure real and complex of different precisions). Does any other language have pure imaginary types? I don't know off-hand.

-Ben

I wonder about them too.  They seem to violate the principle of minimalism in the language design.

Sometimes one must lop off numerical errors when a complex result is known to be pure real or imaginary, confident in the knowledge that any (small) residual is roundoff error.  That is easy enough with complex numbers.  As long as D offers polar and rectangular complex numbers, I am happy and don't need pure imaginaries.

Mark

Ben Hinkle says...
>
>> ifloat = imaginary float
>> idouble = imaginary double
>> ireal = imaginary real
>
>I wonder about these.

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:b0kar8$2h6$1@digitaldaemon.com...
> >A lot of people like the idea of adding the number of bits to the keyword
in
> >one form or another. While it's a practical suggestion, I just don't like the way it looks.
> Hmm, well, you admit that it's practical and lots of people like it but it offends your fashion sense so out it goes! <g>  Oh well.  You are the
Dictator
> of D and rightly so since you are doing all the work and we're just
talkers.

Check out stdint.d which has those aliases for people who prefer them.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:3E2DD8CB.4060308@users.sourceforge.net...
> Walter wrote:
> > "Burton Radons" <loth@users.sourceforge.net> wrote in message news:b0jaqq$2gro$1@digitaldaemon.com...
> >>complex hasn't been used enough yet.  Adding to it violates your rule of never adding a feature that isn't actually necessary.
> > Complex and imaginary are part of standard C99.
> The C pre-processor is part of standard C99.

Ouch!

Walter wrote:
> "Burton Radons" <loth@users.sourceforge.net> wrote in message
> news:3E2DD8CB.4060308@users.sourceforge.net...
> 
>>Walter wrote:
>>
>>>"Burton Radons" <loth@users.sourceforge.net> wrote in message
>>>news:b0jaqq$2gro$1@digitaldaemon.com...
>>>
>>>>complex hasn't been used enough yet.  Adding to it violates your rule of
>>>>never adding a feature that isn't actually necessary.
>>>
>>>Complex and imaginary are part of standard C99.
>>
>>The C pre-processor is part of standard C99.
> 
> 
> Ouch!

Don't take it personally, but we have operator overloading and good complex constants syntax.  The only things float/double complex would provide in D would be storage, some syntax, and builtin array arithmetic: there would be four more types to support for the array arithmetic operations, six if you accept user demand for these operations being as efficient as possible and put in a separate mode for operating on a complex array with a real.

It's not much of a complicating factor, but it'd certainly take a lot more code to support than, for example, generic argument lists.  ;-)

> Carlos wrote:
>> "Mike Wynn" <mike.wynn@l8night.co.uk> escribió en el mensaje
>> news:b0j5oc$2eke$1@digitaldaemon.com...
>> | what about parameterising them
>> |
>> | float => float(32)/real(32)   or even float(1,8,23)
>> | double => float(64)
>> | extended => float(80)
>> | cdouble => complex( float(32 ) ) will be a pair of float(32) and
>> | imaginary( float(32) )

I'd like to propose the question: Are the basic types really worth parameterizing?  There are not so many of them that can be implemented in a straightforward manner.  Those would be integers of size 8, 16, 32 and 64 on current architectures.  And those we already have, although in my opinion it would be rational to name them just int8, int16, int32 and int64.  (uints similarly.)  And reserve int128, etc., if someone decides to introduce them one day.

Integers of variable sizes (with any amount of bits)
- are not needed often
- introduce unnecessary burden for the implementor
- can be implemented as a separate type and are hence unnecessary
- have to be introduced to novices in an awkward way ("here are the
integer types; you should only use integer types of these special
sizes if you want that accessing and counting with them is efficient")

They would be useful in bitfields, though, but seems to me a special case which would of use mostly in low-level structs, and can hence be handled by other means.

And then again, a general-purpose integer (which is 32 bits now, possibly 8 bits on a microwave, 16 bits on an MC68000 based system and 64 bits in a couple of years) should be simply called "int".

Or "Int" if one believes that consistency with capitalized type names is really really important.

I believe that the reason that there are no bit sizes spelled out in the basic types is legacy.  After all, at the time when C was designed there were some pretty peculiar machines around, including ones with 36 bit words, so having things like int8 (or even byte, since a byte could have been from 6 to 12 bits), int16 and int32 wouldn't have been probably reasonable.

After that, everybody's been plagiarizing the C names, so as a result, we have int, short, long and even monstrosities such as "unsigned long long"...

But now we can pretty much assume that everything is a power of two, even on small embedded devices. (I think -- if someone knows of some really weird processor, please enlighten us.)

Ilya Minkov <midiclub@8ung.at> writes:
> And then a mess of fixed-size types:
>   - Byte: it is what it is, unsigned; (well done!)

'byte' (as in 8-bits, or 'officially' octet) is a Good Thing to have in a language; it's probably here to stay.

>   - Word: it is what it is, unsigned; (well done!)

But of 'word' I don't think of so kindly, because it can (as has been
pointed out) mean practically anything.  Besides, word sounds a
microsoftism (because of its usage in DWORD and what you have in the
Windows APIs).  Yech ;)

> So, there should be at least "generic" types representing the following:
>   - signed integer;
>   - extended real;
>   - extended imaginary;
>   - extended complex.
> Possibly a unsigned integer, although i think "unsigned" belogs rather
> into the space considerations, and hence is not necessarily requiered
> as a generic.

Unsigned can also serve as documentation, in which it's pretty much the same as the precondition (x >= 0) but more terse; consider:

interface TForwardIterator
{
  T get();
  void advance() { advance(1); }
  void advance(uint steps);
  bool valid();
}

as opposed to

interface TForwardIterator
{
  T get();
  void advance() { advance(1); }
  in { assert(steps >= 0); }
  void advance(int steps);
  bool valid();
}

(Note the shameless usage of code inside an interface ;)

In addition, I prefer doing my bit operations on unsigned integers although this might be just old C superstition.  Hmm.  You might not have meant what I assumed -- I considered your proposal to be "dropping the whole concept of unsigned from the language", which might have been wrong :)

-Antti

Antti Sykari wrote:
>>Carlos wrote:
> I'd like to propose the question: Are the basic types really worth
> parameterizing?  There are not so many of them that can be implemented
> in a straightforward manner.  Those would be integers of size 8, 16,
> 32 and 64 on current architectures.  And those we already have,
> although in my opinion it would be rational to name them just int8,
> int16, int32 and int64.  (uints similarly.)  And reserve int128, etc.,
> if someone decides to introduce them one day.

The only use is in conjunction with int-parametrized templates.

> Integers of variable sizes (with any amount of bits)
> - are not needed often
> - introduce unnecessary burden for the implementor

There exists a "simplified" implementation, which is easy, limited to sizes which make sense.

> - can be implemented as a separate type and are hence unnecessary
> - have to be introduced to novices in an awkward way ("here are the
> integer types; you should only use integer types of these special
> sizes if you want that accessing and counting with them is efficient")

They don't need to be introduced to novices, novices are to be introduced the generic types. Do you think a nothing-meaning name would say a novice: "Here you may only put numbers in range from .. to .."?
How long is unsigned long long? As long as its name or even longer? :>

These simplified names are only OK for FP, where you can (more or less) always assume you have enough range, but you need more or less precision - it doesn't affect too much.

> They would be useful in bitfields, though, but seems to me a special
> case which would of use mostly in low-level structs, and can hence be
> handled by other means.

They are already taken care of, with bitarray. But bitarrays of cerain sizes might mutate to integers :>

> And then again, a general-purpose integer (which is 32 bits now,
> possibly 8 bits on a microwave, 16 bits on an MC68000 based system and
> 64 bits in a couple of years) should be simply called "int".

Right!

> Or "Int" if one believes that consistency with capitalized type names
> is really really important.

The Emperor is do decide that.

> I believe that the reason that there are no bit sizes spelled out in
> the basic types is legacy.  After all, at the time when C was designed
> there were some pretty peculiar machines around, including ones with
> 36 bit words, so having things like int8 (or even byte, since a byte
> could have been from 6 to 12 bits), int16 and int32 wouldn't have been
> probably reasonable.

Do you call this "words"? My fist computer is now as old as I am - twenty. I got it 12 years ago, and since i've read its manual back then i'm pretty much sure a "word" in a general sense is 2 bytes. Though it wasn't the "processor's word", which was 8. That's what leads to confusion, is that "word" has 2 meanings. And no, there was no Microsoft back then.

> After that, everybody's been plagiarizing the C names, so as a result,
> we have int, short, long and even monstrosities such as "unsigned long
> long"...
> 
> But now we can pretty much assume that everything is a power of two,
> even on small embedded devices. (I think -- if someone knows of some
> really weird processor, please enlighten us.)

That's what systems D is created for. D is not supposed to support some less-than-32-bit wizardry.

> Unsigned can also serve as documentation, in which it's pretty much
> the same as the precondition (x >= 0) but more terse; consider:

Right, but novices are not concerned.

> In addition, I prefer doing my bit operations on unsigned integers
> although this might be just old C superstition.  Hmm.  You might not
> have meant what I assumed -- I considered your proposal to be
> "dropping the whole concept of unsigned from the language", which
> might have been wrong :)

Well, a MUL is a bit faster than IMUL. And shifts become non-ambiguous. It is good to use unsigned when you know what to use it for, just as with width-named integers. You don't leave unsigned out when you don't make it available as "generic". It just stays with width-named types.

BTW, I think that FP numbers have to have vague names, because their precision and range are not so bit-critical as with integers. Like single, double, extended.

-i.

> 
> -Antti

"Antti Sykari" <jsykari@gamma.hut.fi> wrote in message news:86el75o7mw.fsf@hoastest1-8c.hoasnet.inet.fi...
> > Carlos wrote:
> >> "Mike Wynn" <mike.wynn@l8night.co.uk> escribió en el mensaje
> >> news:b0j5oc$2eke$1@digitaldaemon.com...
> >> | what about parameterising them
> >> |
> >> | float => float(32)/real(32)   or even float(1,8,23)
> >> | double => float(64)
> >> | extended => float(80)
> >> | cdouble => complex( float(32 ) ) will be a pair of float(32) and
> >> | imaginary( float(32) )
>
> I'd like to propose the question: Are the basic types really worth parameterizing?  There are not so many of them that can be implemented in a straightforward manner.  Those would be integers of size 8, 16, 32 and 64 on current architectures.  And those we already have, although in my opinion it would be rational to name them just int8, int16, int32 and int64.  (uints similarly.)  And reserve int128, etc., if someone decides to introduce them one day.
>

at first I though you disiked int(32)/int32 and int(16)/16
but realised you mean allowing int(3) or int(6)
that was not my plan,
int(n) where n is 8*(2^N) where N 0..3 (or bigger) (auto promotion to
phobos::bn ?)

> Integers of variable sizes (with any amount of bits)
> - are not needed often
> - introduce unnecessary burden for the implementor
> - can be implemented as a separate type and are hence unnecessary
> - have to be introduced to novices in an awkward way ("here are the
> integer types; you should only use integer types of these special
> sizes if you want that accessing and counting with them is efficient")
>
> They would be useful in bitfields, though, but seems to me a special case which would of use mostly in low-level structs, and can hence be handled by other means.
>
> And then again, a general-purpose integer (which is 32 bits now, possibly 8 bits on a microwave, 16 bits on an MC68000 based system and 64 bits in a couple of years) should be simply called "int".

no, not back to an int is not longer than a long and no short than a short! fixed sizes are much much better (allowing a version to detect the CPU int size is OK for those who care about how efficient operations that do not require fixed widths, of can be perfroms more efficiently with longer ints)

>
> Or "Int" if one believes that consistency with capitalized type names is really really important.
>
> I believe that the reason that there are no bit sizes spelled out in the basic types is legacy.  After all, at the time when C was designed there were some pretty peculiar machines around, including ones with 36 bit words, so having things like int8 (or even byte, since a byte could have been from 6 to 12 bits), int16 and int32 wouldn't have been probably reasonable.
>
> After that, everybody's been plagiarizing the C names, so as a result, we have int, short, long and even monstrosities such as "unsigned long long"...
>
> But now we can pretty much assume that everything is a power of two, even on small embedded devices. (I think -- if someone knows of some really weird processor, please enlighten us.)

I have heard tails of a 17 bit CPU, (the history was the original designers put a 17bit memory bus to allow parity checking, the management said, if its got 17 bits, it should use them all parity is a waste (so they put in a 17 bit alu))

not idea about the addressing or if it had byte support.

>
> Ilya Minkov <midiclub@8ung.at> writes:
> > And then a mess of fixed-size types:
> >   - Byte: it is what it is, unsigned; (well done!)
>
> 'byte' (as in 8-bits, or 'officially' octet) is a Good Thing to have in a language; it's probably here to stay.
>
> >   - Word: it is what it is, unsigned; (well done!)
>
> But of 'word' I don't think of so kindly, because it can (as has been
> pointed out) mean practically anything.  Besides, word sounds a
> microsoftism (because of its usage in DWORD and what you have in the
> Windows APIs).  Yech ;)
>
> > So, there should be at least "generic" types representing the following:
> >   - signed integer;
> >   - extended real;
> >   - extended imaginary;
> >   - extended complex.
> > Possibly a unsigned integer, although i think "unsigned" belogs rather
> > into the space considerations, and hence is not necessarily requiered
> > as a generic.
>
> Unsigned can also serve as documentation, in which it's pretty much the same as the precondition (x >= 0) but more terse; consider:
>
> interface TForwardIterator
> {
>   T get();
>   void advance() { advance(1); }
>   void advance(uint steps);
>   bool valid();
> }
>
> as opposed to
>
> interface TForwardIterator
> {
>   T get();
>   void advance() { advance(1); }
>   in { assert(steps >= 0); }
>   void advance(int steps);
>   bool valid();
> }
>
> (Note the shameless usage of code inside an interface ;)
>
> In addition, I prefer doing my bit operations on unsigned integers although this might be just old C superstition.  Hmm.  You might not have meant what I assumed -- I considered your proposal to be "dropping the whole concept of unsigned from the language", which might have been wrong :)

Java has no unsigned int values (well char is an unsigned storage value,
causes zero extension to int)
90% of the time its ok;
checking that x >= 0 and x <= range(unsigned) can not be coded as (
(unsigned)x < range )
and you have a put a few &0xFFFF 's places

what about the following

int32 i;
int16 smaller = -1;

 i = j + k;   // always signed operations;
i = j & foo;  // always unsigned operations
i = smaller;  // signed extension
i = unsigned( smaller ); // i will now be 0x0000FFFF same effect as writing
i = smaller & 0xFFFF;

i = smaller & 0xFF000000; (& is unsigned so will be 0x00000000 if smaller
is -1)
i = cast(int32)smaller & 0xFF000000 ( promotes to int32 signed so i =
0xFF000000);
i = smaller + 2 ( promotes to int32 signed so i = 1);
i = unsigned(int32)smaller + 2 ( promotes to int32 unsigned so i =
0x00010001);

smaller = cast(int16)i;  // smaller loaded with the lower 16bits (so sign
change may occur)


if ( i < j ) // signed extension if reqd

if ( i unsigned(<) j ) // zero extension if reqd



>
> -Antti