tags 18245 notabug
close 18245
thanks
Nala Ginrut <nalagin...@gmail.com> writes:
> I've imported srfi-1, but after some modifications, the program happens
> not to use any srfi-1 symbols, then there's the problem that one of the
> rule in syntax-rules can't be found and threw error.
> It works when I removed useless srfi-1 from imported list.
The problem is that srfi-1 exports a 'drop' procedure, and 'drop' is
also used as a syntax-rules literal in your macros. Literals are
matched as follows: if the literal identifier has the same name and the
same binding where the macro is defined and where it is used, then
there's a match. If the identifier is not bound in either place, then
there's also a match.
However, in this case 'drop' is not defined where the 'sql-alter' macro
is defined, but it _is_ defined to a procedure in srfi-1 in your example
module where it is used. Therefore, the macro does not consider the
'drop' to be a match for the literal it's looking for.
This is similar to the issue that if you define 'else' to be something
in a module (or import it from somewhere), then 'else' will no longer
have its special meaning in a 'cond' form. Ditto for '=>'.
There is some question about whether these rules for matches literals
are the best ones, and the issue has been debated during the R7RS
standardization process, but nonetheless the standards are clear on this
matter.
I recommend choosing literals that are not likely to be bound in modules
that use your sql macros.
I'm closing this.
Regards,
Mark
