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

*To*: Andrew Robbins <andjrob@x>*Subject*: Re: [Scheme-reports] Proposal for New Complex Number Syntax*From*: Stefan Edwards <saedwards.ecc@x>*Date*: Mon, 26 Mar 2012 10:51:32 -0400*Cc*: scheme-reports@x*In-reply-to*: <CAAMbixKytwB84FBHACz2oreaL8p5Zz-SoNSdK0MpVXUmvPMQ+Q@mail.gmail.com>*References*: <CAPbE8xAgpyXhBkCwByHnZV6U3gERW4JRQS5nOrOK82-Zdgp4cA@mail.gmail.com> <CAAMbixKytwB84FBHACz2oreaL8p5Zz-SoNSdK0MpVXUmvPMQ+Q@mail.gmail.com>

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.

_______________________________________________ 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:*Andrew Robbins <andjrob@x>

**References**:**[Scheme-reports] Proposal for New Complex Number Syntax***From:*quad <quad@x>

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

- Prev by Date:
**Re: [Scheme-reports] Proposal for New Complex Number Syntax** - Next by Date:
**Re: [Scheme-reports] Proposal for New Complex Number Syntax** - Previous by thread:
**Re: [Scheme-reports] Proposal for New Complex Number Syntax** - Next by thread:
**Re: [Scheme-reports] Proposal for New Complex Number Syntax** - Index(es):