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

[Andrew Robbins <andjrob@x>]

@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@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.

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports