On Wed, May 4, 2011 at 10:30 PM, Andre van Tonder <andre@het.brown.edu> wrote:
>
>> You're right. An implementation conforming to R5RS should fail here.
>> '=>' is not allowed in the 'else' clause.
>
> No, I claimed that a correct implementation must sucxceed and give 1.  Macro
> hygiene reequires it to.  See the explanation below.

I see your point. Looks like R5RS contradicts itself and there is
simply no correct implementation (one that preserves semantics of
'cond', 'case' etc. and has hygienic macros). Implementations behaving
the way you want would violate other parts of the specification.

> Again, I calim that teh spec requires the answer to be 1, again because of
> macro hygiene.  I would suggest that you reread the section on macro
> expansion:
>
>   If a macro transformer inserts a binding for an identifier (variable or
>   keyword), the identifier will in effect be renamed throughout its scope to
>   avoid conflicts with other identifiers.
>
> In other words, the => in

Except that 'else' or '=>' are not identifiers so the whole concept of
bindings simply does not apply to them.

It would be great if R7RS could clarify what to do in such situation.
I found that most actively maintained implementations at some point
went in the direction of treating 'else' like an ordinary identifier.
If that's the consensus and intended behavior then section describing
'cond' syntax and semantics should be rewritten.

Andrzej

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