[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] ANN: first draft of R7RS small language available
On Tue, May 3, 2011 at 11:35 PM, Andre van Tonder <andre@x> wrote:
>
> Here is a good example illustrating the problems of your proposed
> implementation.
Actually, after reading through all the answers, I'm coming to a
conclusion that my implementation is fine. It's only the R5RS that is
a bit underspecified (maybe).
> (define-syntax convert-to-boolean
> (syntax-rules ()
> ((_ exp)
> (cond (exp #t)
> (else #f)))))
>
> (let ((else #f))
> (convert-to-boolean else))
>
> What answer should he get?
> What answer would he get in your implementation?
My implementation will return #f here (that is once I have macro
expansion in place) because it expands to:
> (let ((else #f))
> (cond
> (else #t)
> (else #f))) => #f
'Cond' itself is a built-in syntax in my implementation but even if it
wasn't it still should expand to a form producing #f (according to
R5RS).
I do realize that this probably wasn't what you wanted to show and
perhaps there are cases where my implementation will produce an
"unexpected" result but:
1. That's what R5RS explicitly asks me to do. In fact, if I evaluated
'else' instead I would be violating the specification.
2. *If* in some scenarios you can get two different results in two
different and correct implementations (perhaps one implementing 'cond'
as a macro, another with 'cond' being a built-in syntax), it only
means you hit an unspecified behavior. In such a case implementation
is free to produce any result, signal an error etc.
I'm not sure if (2) is a real concern, the example you gave works or
should work just fine in any conforming implementation. Can you
produce one that exposes the issue?
> Now imagine a user who knows that there are no reserved words in Scheme and
> who knows nothing of the implementation of convert-to-boolean
I understand your concern and agree with it (assuming such undefined
behavior really exists). But this is coming straight from the spec,
not from an implementation error or a design decision. This raises a
question is whether the spec should be fixed or not. The solution you
propose requires that essentially any mention of 'else' should be
removed from the 'cond' specification.
Andrzej
_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports