Replacing built-in complex? What's this about?
SeeWebsiteForEmail at erdani.org
Sat Dec 27 15:57:27 PST 2008
Andrei Alexandrescu wrote:
> Stewart Gordon wrote:
>> Andrei Alexandrescu wrote:
>>> 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.
>>> Cartesian vs. polar is an opt-in, not a must. All operations work
>>> with both representations, obviously with different performance
>> 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.
>>> 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
> 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.
I meant makeMap("a", 1, "b", 2), and also meant to finish my message,
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.
More information about the Digitalmars-d