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

*To*: scheme-reports@x*Subject*: [Scheme-reports] Proposal for New Complex Number Syntax*From*: quad <quad@x>*Date*: Sun, 25 Mar 2012 14:48:10 -0600

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@x http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports

**Follow-Ups**:**Re: [Scheme-reports] Proposal for New Complex Number Syntax***From:*John Cowan <cowan@x>

**Re: [Scheme-reports] Proposal for New Complex Number Syntax***From:*Jussi Piitulainen <jpiitula@x>

**Re: [Scheme-reports] Proposal for New Complex Number Syntax***From:*Andrew Robbins <andjrob@x>

- Prev by Date:
**Re: [Scheme-reports] Rounding procedures with inf/nan** - Next by Date:
**[Scheme-reports] Ref cells** - Previous by thread:
**Re: [Scheme-reports] Rounding procedures with inf/nan** - Next by thread:
**Re: [Scheme-reports] Proposal for New Complex Number Syntax** - Index(es):