Remove complex and imaginary types?

[renoX]

Bruce Adams a écrit :
> On Mon, 07 Jan 2008 13:21:21 -0000, renoX <renosky at free.fr> wrote:
> 
>> Robert Fraser Wrote:
>>
>>> Oskar Linde wrote:
>>> > Walter Bright wrote:
>>> >> The issue comes up now and then about why have complex and imaginary
>>> >> types, rather than using structs? All but one of the advantages of
>>> >> having them be core types can be addressed with advancing compiler
>>> >> technology. Getting rid of them will release 6 keywords, and make the
>>> >> core language simpler. Given the increasing complexity of D, this 
>>> will
>>> >> help.
>>> >>
>>> >> The remaining advantage is that of imaginary literals, i.e. the i
>>> >> postfix:
>>> >>
>>> >>     3 + 5i
>>> >>
>>> >> Assuming we solve the literal problem, existing code would only need
>>> >> to add:
>>> >>
>>> >>     import std.complex;
>>> >>
>>> >> to acquire complex and imaginary types.
>>> >
>>> > Sounds like a good idea. Complex math is probably only used in a very
>>> > small subset of D code, and if most advantages of having the types 
>>> built
>>> > in are rendered irrelevant I see no reason not to take this 
>>> opportunity
>>> > to simplify the language.
>>> >
>>> > Regarding literals, I'd say this is would be an adequate 
>>> replacement for
>>> > the above expression:
>>> >
>>> >     3 + 5*i
>>> >
>>> > And last, getting rid of the creal and ireal keywords can only be a 
>>> good
>>> > thing. :)
>>> >
>>>
>>> The identifier "i" is rather frequently used, so I don;t think that's a
>>> good idea. I'd prefer an opPostfix or something that allows literals
>>> with postfixes to be converted to different types. This would be
>>> especially nice for dealing with units, i.e.:
>>>
>>> writef("%s", toMiles(10km + 13ft));
>>
>> I think that you have the right suggestion here: what's wrong about 
>> the complex is that it is a too specific mechanism, having a generic 
>> built-in postfix unit mechanism would allow complex, quaternion, unit 
>> libraries.. which is very nice.
>>
>> In theory there is no difference between "cast(km)10 + cast(ft)13" and 
>> "10km + 13ft" but in practice there is a big one: the second one is 
>> much more readable!
>>
>> Regards,
>> renoX
>>
> Ignoring my previous post this rings a bell. I'm sure I've seen it in
> another language somewhere, probably a dynamic one.

Fortress has this:
http://en.wikipedia.org/wiki/Fortress_%28programming_language%29

It's a language made by Sun for HPC.

Regards,
renoX