Remove complex and imaginary types?

[Walter Bright]

Georg Wrede wrote:
> Assuming the opponents of the D programming language are not reading 
> this, I'd like to remind you of the upsides.

Sure. Hearing both sides is why I posted the query.

> A language that is C(++) like, and that endorses Complex and Imaginary 
> types right in the language itself, gains a few points in any 
> "cross-the-tees" language comparison. Additionally, while any 
> "self-respecting professional" doesn't let his reputation degrade into 
> falling for such "mundaneties", some of the critics (especially those 
> who actually are capable of creating their own opinion based on their 
> experience and intellect, as opposed to the average opinion at the golf 
> club), surely would welcome the notion of having these data types 
> chiseled right into the language -- irrespectively of whether there is a 
> Canonical library implementation or not.

I wouldn't remove it from the core language without having a complete 
standard library implementation ready to go.


> IMHO, 
> the notion of having them as Fundamental, or Canonical Types in the 
> language, is totally decoupled from the fact that they are or not are 
> handled in some "bundled library".

I don't agree. Things that should go into the core language are things 
that don't work very well as libraries. If they do work well as 
libraries, then it's hard to see the value of putting them in the core.


> The fact that they are recognised in the language itself, is far more 
> valuable than whether they are at all (or Perfectly) addressed in some 
> library (included or not, or even that you have to buy at (possibly 
> outrageous) cost).

They'd be standardized and included with any standard conforming D 
implementation.

>> Getting rid of them will release 6 keywords, and make the core 
>> language simpler.
> 
> Now, this is the one subject that gets me downright ballistic. During 
> the (some six) years I've been a part of D, I have constantly had a 
> problem with this keyword number issue.
> 
> I've studied languages, I've taught Computer Programming for years at 
> University Level, and, to this day, I haven't got a compelling answer to 
> "why less keywords is Better, "Even at the cost of confusing any or all 
> of the students of a particular language"".
> 
> I've also studied Natural Languages (as in Finnish, Swedish, English, 
> German, Spanish, Russian, French), and during those years, I've gotten a 
> fair idea of the relation of the number of words versus the number of 
> concepts, and how these relate to the understandability and learning 
> speed of them.
> 
> As a result of this all, I'm definitely of the opinion that "one concept 
> warrants one word", and that "the same word for different purposes is 
> poison", and that "the same concept with different words is poison".

While I agree that lots-o-keywords is not necessarily a bad thing, it is 
an indication that all might not be well with the language design. A 
perfect language would have a very small number of orthogonal concepts, 
from which elegant constructs can be built. For example, closures are a 
simple concept, which obsoletes the more complex feature functors.

> (Do I have to say "const", anybody???")

Oddly enough, the current const regime is the simplest of all the proposals.

>> The remaining advantage is that of imaginary literals, i.e. the i 
>> postfix:
>>
>>     3 + 5i
> 
> I'd really like to reserve the above phrase to be reserved to mean an 
> imaginary number. If one has the library delivered right with the 
> standard compiler or if one has to walk around the Globe in search of 
> the One library that actually implements it, I'd still want to have this 
> particular notation reserved (in the Language Grammar itself) for this 
> particular purpose.

I do too. And been thinking along the lines of simply putting a hack in 
that the postfix 'i' means that it's a literal of type 'imaginary', and 
the compiler looks to see if "std.complex" was imported.

This isn't as outlandish as it sounds, as there's precedent for it both 
in C++ <typeinfo> and java.lang.String, as well as D's Object.