Sure, 0 i just works, but programs are not limited to literals they
also involve variables...
One question that soon arise is complex extension of some intrinsic
functions, say arcSin for example.

Solution 1)
we extend the Number>>#arcSin with a complex extension and can write (2 arcSin).
Drawback: we loose the ability to raise a DomainError when you don't
want a complex...

Solution 2)
we force a complex conversion (2 i arcSin) to access the complex extension.
Drawback: some functions might return a Number rather than a Complex
and we end up by forcing asComplex sends scattered all over our
methods.

Solution 3)
we distinguish arcSin from its complex extension, say #complexArcSin
for example.
Drawback: we loose some polymorphism... we might then need a plethora
of selectors for #quaternionArcSin, #squareMatrixArcSin etc... though
they are all defined by the same serie.

None of these really please me...

Anyway I'm interested in cleaning and extending trunk if necessary.

Nicolas

2011/4/20 Bert Freudenberg <bert at freudenbergs.de>:
> On 20.04.2011, at 06:56, Rodney Polkinghorne wrote:
>>> Be sure to look at class Complex in the image.
>>
>> I found that, tried it, and got sick of saying "0 asComplex" in about
>> two minutes.  Someone must have been there before; Number currently
>> accepts an #argument message, and answers 0 or pi according to sign.
>> I think everything that knows its modulus and argument should know its
>> real and imaginary parts.
>
> That would be trivial to add to Number. What else do you think is missing?
>
>> I like the syntactic pun by which Number accepts a message #i.
>
> So why don't you write 0i instead of "0 asComplex"?
>
> - Bert -
>
>
>
>