@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 On Mon, Mar 26, 2012 at 10:51 AM, Stefan Edwards <saedwards.ecc@gmail.com> wrote: > > > On Mon, Mar 26, 2012 at 10:29 AM, Andrew Robbins <andjrob@gmail.com> 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@scheme-reports.org http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
