I vote against this proposal.
Here's why: the slippery slope.

Why stop there? Why remove only complex notation, when you can get rid
of nasty rational notation too! In fact, we could add an entire new
class of syntax for all exact numbers at the same time! Instead of
X+Yi we would write #e(+ X (* Y (sqrt -1))) and instead of N/D we
would write #e(/ N D). Then we could add an extra precision argument
to exact->inexact and number->string so we could get a billion digits
of pi/2; I mean #e(/ (acos -1) 2).

Pretty soon, you'll be requiring that every implementation include
libgmp, which many do in order to support rationals, but that's beside
the point. And in order to prevent people from including things like
user-defined functions and ports and if expressions, by requiring only
mathematical functions, you'd also end up with a new subsyntax which
is even more complex than complex notation.

Regards,
Andrew Robbins

On Sun, Mar 25, 2012 at 4:48 PM, quad <quad@symbo1ics.com> wrote:
> Hello all.
>
> I propose that the syntax for complex numbers be changed to something
> more Scheme-like.
>
> First and foremost, I believe there needs to be a reduction in as many
> lexical special cases as possible. Complex numbers are one of the more
> complicated types of lexemes in R7RS. Naturally, complex numbers can
> be expressed as a record with two fields, the real part and the
> complex part. However, in the present syntax, which is "algebraic" in
> nature, this idea is not captured. Note that in the report, the
> specification for complex number syntax takes five lines of grammar.
>
> Instead, I propose one uses a "sharp-reader" syntax that is much more
> natural in the Scheme world, similar to what Common Lisp has. I think
> this is completely justified by the general trend of sharp-signs for
> special syntax in the new standard (e.g., bytevectors, bytes, number
> of a different radix).
>
> Formally, I propose the following syntax for the construction of a
> literal (autoquoted) rectangular complex number:
>
>   <carg> ::= <real> | "+inf.0" | "-inf.0"
>   <complex> ::= "#c(" <carg> <carg> ")"
>
> such that
>
>   #c(a b)
>
> represents the complex number (+ a (* b (sqrt -1))).
>
> If we must have a polar syntax, then we can make this more elaborate:
>
>   <carg> ::= <real> | "+inf.0" | "-inf.0"
>   <complex> ::= "#cr(" <carg> <carg> ")"
>               | "#cp(" <carg> <carg> ")"
>
> where "#cr" is the syntax for a rectangular complex number, and "#cp"
> would be the syntax for a polar complex number. Formally,
>
>   #cp(a b)
>
> represents the complex number (* a (exp (* (sqrt -1) b))).
>
> One could even do a combination of the above two ideas, where #c
> always represents a rectangular complex number, and #cp represents a
> complex number in polar form, which has the benefit of being simpler
> and even more compatible to other lisps.
>
> The problem (well, a non-problem in my experience) would be that this
> deviates from the previous standard. I think this is justified by
> making Scheme lexically *simpler* to implement, simpler to serialize
> and represent, and more compatible with the rest of the standard. A
> major benefit of this approach is that it frees the usage of "@"
> (except for unquote splicing), which seems wasteful for representing a
> particular form of complex numbers.
>
> Thanks,
>
> Robert Smith
>
> _______________________________________________
> Scheme-reports mailing list
> Scheme-reports@scheme-reports.org
> http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports