Hi Andy,

On Mon, Aug 15, 2011 at 6:47 PM, Andy Wingo <wingo@pobox.com> wrote:
> Hi Alex,
>
> Thanks for writing this page, it is on the whole a good document.

Thanks.  Please bear in mind it's a work in progress,
and where rationales are given they are intended to
be the briefest of summaries.  I think supplementing
the diff with links to further references rather than
extended summaries would be more appropriate.

It's also an incomplete list.  If there was a diff somewhere
between R5RS and R6RS it would be easier.

> A couple of points come to mind:
>
>> Identifier syntax is not provided. [...]
>
> I do not think that this is a suitable justification.  (I think it's
> fine to not have a justification FWIW; better than a bad justification.)

On the contrary, if the justification is indeed bad
I think it's better to list it, so others can point out
what's wrong with it.

This particular case has been argued extensively,
and is brought up multiple times in the R6RS
ratification votes.  I can dig up references after I
catch up on mail, but it is hardly what you could
call a "bad justification", even if you disagree with it.

> In particular you can make the same argument about not knowing whether a
> particular form is an expression or a definition.  I guess my question
> is, why is this a good argument against identifier-syntax?

What is the point of this reductio ad absurdum?  Are
you suggesting we remove definitions (or expressions?)
from the language?

> Implementations may (and some will) support the even/odd example,
> however.  I hope that such an implementation will still be deemed a
> compatible Scheme system.

Yes, of course.  R7RS does not in general explicitly prevent extensions.

>> The division operators div, mod, div-and-mod, div0, mod0 and
>> div-and-mod0 have been replaced with a full set of 15 operators
>> describing 5 rounding semantics.
>
> R7RS does include the equivalents of div and mod, but not div0 and
> mod0.  The centered/ that I suggested was the div0/mod0 equivalent; I
> gave arguments for it, but it was not deemed to be useful.

Thanks, I'll clarify that in the diff.  Personally I voted against
it because there are just too many division operators going
around, and it's not clear to me what they're all used for.  I'd
just as soon stick with R5RS until we actually figure this out.

Real-world examples of any of the operators under discussion
would be helpful.

>> When a result is unspecified, it is still required to be a single
>> value, in the interests of R5RS compatibility.
>
> I still consider this to be an unnecessary restriction, and a shameful
> one at that.

I'll reply to this separately.

--
Alex

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