On Wed, May 4, 2011 at 12:07 PM, Andre van Tonder <[email protected]> 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 before. Andrzej _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
