[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Scheme-reports] Proposal for New Complex Number Syntax

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.


Robert Smith

Scheme-reports mailing list