Mathematicians talk in terms of integers, real numbers, and complex numbers. These are terms everyone understands, including C programmers.  I believe that a new language should prefer the term "real" over the old C-ish "float," "double," and "extended" terms.

Most of us have been C programming so long that we seldom take a step back to look at these name choices objectively.  They are pretty bad.  They reflect geek-Unix lingo, not rational semantics.

Some are nouns (int), some are adjectives (short, float, double) and the adjectives are not even consistent within the same category (float designates a floating-point characteristic, double describes a specific precision, while extended describes a non-specific precision which varies across platforms).

It seems to me that something like <noun><modifier> is the right way to name these types.

I'd really love Real32, Real64, Real80, Real128.  Someone mentioned aliases, but turn that argument on its head.  Why not use rational semantic choices for the *native* types, and use aliases for ugly C-isms like float and double?

Think about it! <g>

Mark

You're right, of course, but I want to retain a C flavor as far as reasonable.

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:amb0n4$30p7$1@digitaldaemon.com...
> Mathematicians talk in terms of integers, real numbers, and complex
numbers.
> These are terms everyone understands, including C programmers.  I believe
that a
> new language should prefer the term "real" over the old C-ish "float,"
"double,"
> and "extended" terms.
>
> Most of us have been C programming so long that we seldom take a step back
to
> look at these name choices objectively.  They are pretty bad.  They
reflect
> geek-Unix lingo, not rational semantics.
>
> Some are nouns (int), some are adjectives (short, float, double) and the
> adjectives are not even consistent within the same category (float
designates a
> floating-point characteristic, double describes a specific precision,
while
> extended describes a non-specific precision which varies across
platforms).
>
> It seems to me that something like <noun><modifier> is the right way to
name
> these types.
>
> I'd really love Real32, Real64, Real80, Real128.  Someone mentioned
aliases, but
> turn that argument on its head.  Why not use rational semantic choices for
the
> *native* types, and use aliases for ugly C-isms like float and double?
>
> Think about it! <g>
>
> Mark
>
>

In article <ambh6t$g3t$1@digitaldaemon.com>, Walter says...
>
>You're right, of course, but I want to retain a C flavor as far as reasonable.
>

Could you do that by relegating the C names to aliases in Phobos?  You might be surprised how many C programmers would opt for the better names if given the choice.

M.

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:ambkd0$jkf$1@digitaldaemon.com...
> In article <ambh6t$g3t$1@digitaldaemon.com>, Walter says...
> >
> >You're right, of course, but I want to retain a C flavor as far as reasonable.
> >
>
> Could you do that by relegating the C names to aliases in Phobos?  You
might be
> surprised how many C programmers would opt for the better names if given
the
> choice.

I agree. I am teaching C for beginners. Explaining the difference between float, double and long double for them is a difficult task, considering the unfortunate names. Escpecially when they already learned the "long int" spelled shorter as "long". I think it would me much easier if some logical convetion was followed, such as mentioned here.

I disagree. C's language base is already so large, why should we add another dialect using aliases. Simply makes the language bigger and harder to read. People will be more inclined to only learn a sub-set of the language. That is why the addition of any  keyword must be considered with care. I know it's only one word, but I'm talking in a general sense, where do you stop. I don't what to have to know 4 different dialects of D to understand it.

Aliasing is generally not the answer.

"Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:ambui8$10ec$1@digitaldaemon.com...
>
> "Mark Evans" <Mark_member@pathlink.com> wrote in message news:ambkd0$jkf$1@digitaldaemon.com...
> > In article <ambh6t$g3t$1@digitaldaemon.com>, Walter says...
> > >
> > >You're right, of course, but I want to retain a C flavor as far as reasonable.
> > >
> >
> > Could you do that by relegating the C names to aliases in Phobos?  You
> might be
> > surprised how many C programmers would opt for the better names if given
> the
> > choice.
>
> I agree. I am teaching C for beginners. Explaining the difference between float, double and long double for them is a difficult task, considering
the
> unfortunate names. Escpecially when they already learned the "long int" spelled shorter as "long". I think it would me much easier if some logical convetion was followed, such as mentioned here.
>
>
>

"anderson" <anderson@firestar.com.au> wrote in message news:amc2o2$15hd$1@digitaldaemon.com...
> I disagree. C's language base is already so large, why should we add
another
> dialect using aliases. Simply makes the language bigger and harder to
read.
> People will be more inclined to only learn a sub-set of the language. That is why the addition of any  keyword must be considered with care. I know it's only one word, but I'm talking in a general sense, where do you stop.
I
> don't what to have to know 4 different dialects of D to understand it.
>
> Aliasing is generally not the answer.

Yes. We don't need the old type names! :-) (short, long, float and double)
Actually I don't consider backward-compatibility so important here.
D should make use of the advantage of "starting with an empty page".

But nothing can/will stop a third party from creating a module with the other set of typenames as aliases, and distribute it. So whatever we choose, both dialects will still be present. The choice here is: which dialect should be the prefered one?

I totally agree.  C compatibility is a neat bonus but shouldn't be the single largest driving force behind language design.

Sean

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:ambkd0$jkf$1@digitaldaemon.com...
> In article <ambh6t$g3t$1@digitaldaemon.com>, Walter says...
> >
> >You're right, of course, but I want to retain a C flavor as far as reasonable.
> >
>
> Could you do that by relegating the C names to aliases in Phobos?  You
might be
> surprised how many C programmers would opt for the better names if given
the
> choice.
>
> M.

I don't think that "real" should be used as a alternated type name to "float", because "float"s are not the same as "real"s. "Float" represents the subset of "real" numbers that can be represented exactly using a base-2 mantissa and exponant (1/3 is a real number, but it isn't a float).

I do agree that D's type names need not be inherited from c/c++ or any other language, and that a consistant and extensible type system would be a big improvement, but I have no idea what they should be, or what
set should be the default...

Alix Pexton.
Webmaster "The D journal"...

Mark Evans wrote:
> Mathematicians talk in terms of integers, real numbers, and complex numbers.
> These are terms everyone understands, including C programmers.  I believe that a
> new language should prefer the term "real" over the old C-ish "float," "double,"
> and "extended" terms.
> 
> Most of us have been C programming so long that we seldom take a step back to
> look at these name choices objectively.  They are pretty bad.  They reflect
> geek-Unix lingo, not rational semantics.
> 
> Some are nouns (int), some are adjectives (short, float, double) and the
> adjectives are not even consistent within the same category (float designates a
> floating-point characteristic, double describes a specific precision, while
> extended describes a non-specific precision which varies across platforms).
> 
> It seems to me that something like <noun><modifier> is the right way to name
> these types.
> 
> I'd really love Real32, Real64, Real80, Real128.  Someone mentioned aliases, but
> turn that argument on its head.  Why not use rational semantic choices for the
> *native* types, and use aliases for ugly C-isms like float and double?
> 
> Think about it! <g>
> 
> Mark
> 
> 

"Mark Evans" <Mark_member@pathlink.com> ha scritto nel messaggio news:amb0n4$30p7$1@digitaldaemon.com...
> Mathematicians talk in terms of integers, real numbers, and complex
numbers.
> These are terms everyone understands, including C programmers.  I believe
that a
> new language should prefer the term "real" over the old C-ish "float,"
"double,"
> and "extended" terms.
>
> Most of us have been C programming so long that we seldom take a step back
to
> look at these name choices objectively.  They are pretty bad.  They
reflect
> geek-Unix lingo, not rational semantics.
>
> Some are nouns (int), some are adjectives (short, float, double) and the
> adjectives are not even consistent within the same category (float
designates a
> floating-point characteristic, double describes a specific precision,
while
> extended describes a non-specific precision which varies across
platforms).

Int(eger) too is an adjective. All of them suppose "number" as the noun they
refer to.
Short, long and double are associated also with float(ing point) or
int(eger).
So: long double -> long double floating point number

> It seems to me that something like <noun><modifier> is the right way to
name
> these types.

I agree.

> I'd really love Real32, Real64, Real80, Real128.  Someone mentioned
aliases, but
> turn that argument on its head.  Why not use rational semantic choices for
the
> *native* types, and use aliases for ugly C-isms like float and double?

I prefer 'float' instead of 'real'. Real "real" numbers are not always
representable in
a floating point representation. Another term could be "rational", but also
rational numbers
can't be fully represented with such notation. And note that there are
inifnite integer
numbers that can't be represented, given one integer format of choice.

A honest language should use: int(XX), fixed(XX,YY), float(XX,YY), but I
suspect
it's too complex for newbies to learn.
Having this possibility would be good, indeed.

Ciao

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:ambkd0$jkf$1@digitaldaemon.com...
> In article <ambh6t$g3t$1@digitaldaemon.com>, Walter says...
> >You're right, of course, but I want to retain a C flavor as far as reasonable.
> Could you do that by relegating the C names to aliases in Phobos?  You
might be
> surprised how many C programmers would opt for the better names if given
the
> choice.

They might be right, but in order to get C programmers to spend some initial time with D, it needs to look like C as far as reasonable. If it looks too different, they won't give D a chance.