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

Re: [Scheme-reports] Proposal for New Complex Number Syntax

On Mon, Mar 26, 2012 at 11:03 AM, Andrew Robbins <andjrob@x> wrote:
@Stefan: Thanks :)

On a more serious note, is there any harm in rewriting
the current syntax a little more clearly? For example:

<complex R> // CURRENT R7RS-draft-6
       = <real R>
       | <real R> '@' <real R>
       | <real R> '+' <ureal R> 'i'
       | <real R> '-' <ureal R> 'i'
       | <real R> <infinity> 'i'
       | <real R> '+' 'i'
       | <real R> '-' 'i'
       | '+' <ureal R> 'i'
       | '-' <ureal R> 'i'
       | <infinity> 'i'
       | '+' 'i'
       | '-' 'i'

<complex R> // MY PROPOSAL
       = <real R>
       | <real R> '@' <real R>
       | <real R> <imag R>
       | <imag R>

<imag R>
       = <explicit sign> <ureal R> 'i'
       | <infinity> 'i'
       | <explicit sign> 'i'

<real R>
       = <sign> <ureal R>
       | <infinity>

or is that grammatically different?

Andrew Robbins

I don't *think* it modifies anything grammatically (although someone may point out a glaring mistake I've made), but I'm not sure it necessarily clarifies the grammar either. It may be a better fit as to how one would go about writing a reader for complex numbers though: one can more easily see a "composition of functions" approach in your grammar versus the original. They both look acceptable to me.
On Mon, Mar 26, 2012 at 10:51 AM, Stefan Edwards
<saedwards.ecc@x> wrote:
> On Mon, Mar 26, 2012 at 10:29 AM, Andrew Robbins <andjrob@x> wrote:
>> 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
> I don't think you have to extend the argument to this level of absurdity
> before it breaks (although this did give me a laugh).
> 0 - complex number notation has been in Scheme and other languages for a
> while, and is pretty close to the mathematical notation used by most
> people.
> 1 - As Mr. Robbins pointed out, why support N/D notation when you could have
> #rat(N D) or #r(N D) as well, which would at least make the numeric types
> more consistent (if you were insisting on this sort of consistency at
> least).
> 2 - I don't think it really matters what the internal representation of a
> type is when we're not signalling intent or following a requirement like
> typed vectors do.
> 3 - Although the argument about reading the lexeme is a valid one, it does
> seem to be a barrier for entry to Scheme implementations (indeed, I fought
> with this too when working on my Scheme system, but I never thought it so
> complex as to require scraping it and starting over).
> Those are my 0.02 NOK anyway.
> Cheers,
>  -- S.
> --
> ====
> Q. How many Prolog programmers does it take to change a lightbulb?
> A. No.

Q. How many Prolog programmers does it take to change a lightbulb?
A. No.
Scheme-reports mailing list