This site is a static rendering of the Trac instance that was used by R7RS-WG1 for its work on R7RS-small (PDF), which was ratified in 2013. For more information, see Home.

Ticket 39: syntax-error

2012-10-05 00:34:07
WG1 - Macros
alexshinn
major
cowan
fixed
source
closed
2010-03-01 09:39:21
defect

Should we have syntax-error parallel to SRFI-23 error? This is evoked when macros are expanded.

There is a definition in JRM's Syntax-Rules Primer using syntax-rules, but it relies on the syntax-rules implementation reporting an unmatchable pattern with a complaint that includes the pattern.

milestone

There's an issue here that no one has brought up. In order for the SYNTAX-ERROR binding to be invoked and evaluated at macro time, it would have to be a macro. This causes a problem if we also want to support later macro systems that allow for arbitrary code evaluation. If a syntax error is desired when the code is being evaluated at macro time, then it can't be a syntax, as it will evaluate and signal the error even when it should not. This necessitates two forms, one syntactic and one procedural. Is this a good thing?

SYNTAX-ERROR is intended to be invoked only from syntax-rules macros. Procedural macros should invoke ERROR (or some lower-level equivalent), and the system would intercept this and report a syntax error, since it is known when we are running macro code and when we are not.

All of the syntax-rules implementations that i have used report syntax errors, if not exactly as described in the ticket, so i don't see why we are multiplying entities here

resolutionfixed
statusnewclosed

The WG voted to accept syntax-error as part of the core.

resolutionfixed
statusclosedreopened
owneralexshinn
statusreopenedassigned
statusassigneddecided
owneralexshinn
statusdecidedwriting
resolutionfixed
statuswritingclosed