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

[Bill Baxter]

On Sun, Dec 28, 2008 at 8:46 AM, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> wrote:
> Stewart Gordon wrote:
>>
>> 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.

Additionally, if you're in Fortran's target demographic it means
you're about 1000x more likely than the average programmer to actually
need complex numbers.

>> 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.

Are you including the ability to use them at compile time among the
illusory advantages?

> 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 agree and think the ability to do this-or-that at compile time is
also in this category.  In an ideal world, *any* D code that doesn't
depend on dynamic data would be runnable at compile time.  A library
implementation of hash tables would then "just work" at compile time
without any special considerations on the part of the developer.  But
I don't think the compiler is quite there yet, so till it is, there is
an advantage to having a built-in hash-table that can run at compile
time.

--bb