Replacing built-in complex? What's this about?

[Andrei Alexandrescu]

Stewart Gordon wrote:
> Andrei Alexandrescu wrote:
> <snip>
>> I think that the justification should go the other way. A feature's 
>> existence must be justified, not its removal.
> 
> I disagree.  It's important to weigh up the benefits against the costs 
> of removing a feature.

Just saying it doesn't make it true. Wait, I did the same :o). My 
justification stems in the philosophy of preferring libraries over core 
features, all things being equal. There are many benefits to that 
philosophy, which makes it prevalent across today's languages. If you 
don't buy into that, we'll have to agree to disagree.

> <snip>
>> Cartesian vs. polar is an opt-in, not a must. All operations work
>> with both representations, obviously with different performance
>> tradeoffs.
> 
> But that's almost a vacuous truth at the moment, because no real 
> operations have been implemented yet.

I should have put the future tense in there. That elevates the statement 
from vacuous truth to intended design.

>>> - D has the potential to supersede Fortran as a scientific 
>>> programming language.  Indeed, "Numerical programmers" is one entry 
>>> in the "Who D is For" list.  So if Fortran has an excuse for built-in 
>>> complex, why not D?
>>
>> Because of advancement in compiler technology.
> 
> So, is complex scheduled for removal from Fortran?

Fortran has too little support for abstraction to accommodate complex as 
a user-defined type gainfully. It also has a great deal of legacy code 
to worry about.

>>> To conclude, while library complex types are a nice idea, there's no 
>>> need for them to replace the built-in complex types.  IMO it would 
>>> work well to keep the built-in complex types, and have std.complex 
>>> available as an alternative for when you want more power than that 
>>> provided by the built-in types.  What's more, std.complex should 
>>> provide conversions between its complex types and the built-in ones.
>>>
>>> Thoughts?
>>
>> I'd say, to paraphrase: "Although built-in complex types are a nice 
>> idea, there's no need for them to replace the library complex types." 
>> I took the liberty to replace "while" with "although" because that 
>> usage of "while" is considered bad style :o).
> 
> They cannot replace the library complex types, because these built-in 
> types came first.

Yes, but in this case there's no right of the first-comer. Just because 
built-in complex was there first does not confer it extra rights beyond 
backwards compatibility, which for D2 is not a major concern.

>> Keeping both complex types around would further degrade justification 
>> for the built-in counterpart.
> 
> You could just as well claim that library implementations of associative 
> arrays, sorting and the like degrade justification for the built-in 
> counterparts.  But it's still useful to have the built-in counterparts.

You see, built-in associative arrays have exactly two advantages:

(a) The type name is very terse, e.g. uint[string] vs. Map!(string, uint).

(b) The literal syntax is also very terse, e.g. [ "a" : 1, "b" : 2 ] vs. 
makeMap!("a", 1, "b", 2).

In my opinion all other alleged advantages are illusory. In fact, having 
builtins wielding too much power is in fact a sign the language design 
didn't go that well: If a built-in type has too many advantages over a 
user-defined type, that only means user-defined types are robbed of that 
many possibilities.


Andrei