On Tue, May 3, 2011 at 11:35 PM, Andre van Tonder <andre@het.brown.edu> 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@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports