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

[Andrei Alexandrescu]

Andrei Alexandrescu wrote:
> 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

I meant makeMap("a", 1, "b", 2), and also meant to finish my message, 
continuing with:

In the case of hashtables both (a) and (b) come about rather often. In 
the case of complex, it's just not so:

(a) A battery of alias declarations take care of the naming issue;

(b) Complex literals are rare, far between, and to be discouraged.


Andrei