Remove complex and imaginary types?

[Bill Baxter]

Bruce Adams wrote:
> On Mon, 07 Jan 2008 08:35:20 -0000, Bill Baxter 
> <dnewsgroup at billbaxter.com> 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.
>>
>> I defer to Don on this one :-)
>>
>> But I will say I seem to have heard arguments like this pretty often: 
>> "Well complex numbers are built-in, and my <new confoobulator> will be 
>> used at least as much as complex numbers."  So that seems a little 
>> telling to me.
>>
> You must surely have noticed people using all kinds of weird and 
> wonderful excuses
> as justifications for their pet new syntax feature proposal. I think 
> complex numbers
> like any other feature have to stand or not on their own.
> 
>> I personally haven't had much need for complex numbers, but I maintain 
>> wrappers for a number of Fortran math libraries which have APIs for 
>> cfloat and cdouble.  My main fear is just that going from built-in to 
>> not means I'll need to maintain different versions of these for D1.0, 
>> D2.0, and maybe D2.0/Tango when that comes out.  Right now I think 
>> they're pretty much version independent.
>>
>> --bb
> 
> My own feeling is if it ain't broke don't fix it. Walter must have 
> something up his
> sleeve if he's thinking of changing it. It could just be cosmetic. 

I think he's sensitive about the number-of-keywords argument people 
sometimes bring up against D.  The count for D could drop by 6 by making 
complex numbers a library.
Anyway, as Don so eloquently pointed out, pure imaginary types of any 
form don't make much sense in a programming language.

> Its common in a new
> language for features to be hard coded and gradually replaced with 
> libraries as the
> language becomes strong enough to support better modularity. I can't 
> think of any other
> language where complex numbers are built in rather than a library (only 
> because I've
> never looked mind). However, I can't think of any language that has a 
> rich enough syntax
> to let you write 3+5i like that. Though I can see it happening in a duck 
> typed language.

I know of two: Fortran and python both have complex numbers built in 
(but neither has a built-in pure imaginary type).

Fortran has em because the language was designed mainly for engineering 
work, and engineers can't live without complex numbers.  At least back 
in 1977 Fortran had no way to define user types, so built-in was the 
obvious choice.

I'm not sure why Python has them built-in.  It doesn't really seem 
necessary.  Maybe Guido just wanted to draw in the engineers.  It even 
uses the engineering convention of j for sqrt(-1). 1+1j rather than 1+1i.

--bb