On Mon, Mar 26, 2012 at 11:03 AM, Andrew Robbins <[email protected]> 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? > > Regards, > 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 > <[email protected]> wrote: > > > > > > On Mon, Mar 26, 2012 at 10:29 AM, Andrew Robbins <[email protected]> > 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 [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
