[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Scheme-reports] ANN: first draft of R7RS small language available

On Wed, May 4, 2011 at 12:07 PM, Andre van Tonder <andre@x> wrote:
> Be that as it may, let me give another example.  I am pretty sure that the
> the spec requires the following to evaluate to 1.
> (define-syntax nonfalse-identity
>  (syntax-rules ()
>    ((_ x)
>     (cond (x => (lambda (x) x))))))
> (let ((else 1))
>  (nonfalse-identity else))  ====> 1
> but I think your implementation will give the wrong result here (or an
> error).

You're right. An implementation conforming to R5RS should fail here.
'=>' is not allowed in the 'else' clause.

> Here is anotehr example, which evaluates a given expression (in case it has
> side effects) and returns 1.  It is a silly way of doing this, but there is
> no doubt that the spec requires the answer to be 1.
> (define-syntax map-to-identity
>  (syntax-rules ()
>    ((_ exp)
>     (cond (#t exp 1)))))
> (let ((=> 0))
>  (map-to-identity =>))   ======> 1

Ditto. A clause with '=>' must contain a single operand procedure (not '1').

> Again, I believe your implementation will return the wrong answer (or an
> error).

I think your concerns about consistency of R5RS are valid. I fully
agree that a user shouldn't care whether the macro implementation uses
'cond' or not. However, I don't agree that the solution is to make the
implementation deliberately incompatible with the spec. This way (e.g.
by evaluating 'else') you break another class of programs that happen
rely on the specified behavior of 'else'.

Personally, I think this should be addressed in R7RS, either by
explicitly informing about limits of the specification (illustrated
with an example like yours) or (better) by fixing this potentially
erroneous behavior by removing 'else' and '=>' syntax. Perhaps it
would be enough to replace them with global variables as you proposed


Scheme-reports mailing list