Re: guile 2.2 : syntax-rules failure?

[Taylan Ulrich Bayırlı/Kammer]

Matt Wette <address@hidden> writes:

> difference in behavior from guile 2.0 to guile 2.2:
>
> === foo.scm =================
> (define-module (foo) 
>   #:export (foo-mac))
>
> (define bar 1)
>
> (define-syntax foo-mac
>   (syntax-rules (bar)
>     ((_ (bar none)) #t)))
>
> === demo.scm =================
> (add-to-load-path (getcwd))
>
> (use-modules (foo))
>
> (foo-mac (bar 1))
>
>
> mwette$ guile20 demo.scm
> mwette$
>
>
> mwette$ guile demo.scm   [<= guile 2.2]
> mwette$ guile demo.scm
> ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
> ;;;       or pass the --no-auto-compile argument to disable.
> ;;; compiling /Users/mwette/proj/scheme/guile/bugs-guile/z/demo.scm
> ;;; WARNING: compilation of 
> /Users/mwette/proj/scheme/guile/bugs-guile/z/demo.scm failed:
> ;;; ERROR: Syntax error:
> ;;; /Users/mwette/proj/scheme/guile/bugs-guile/z/demo.scm:5:0: source 
> expression failed to match any pattern in form (foo-mac (bar 1))
> ice-9/psyntax.scm:1558:32: In procedure expand-macro:
> ice-9/psyntax.scm:1558:32: Syntax error:
> demo.scm:5:0: source expression failed to match any pattern in form (foo-mac 
> (bar 1))

What Guile 2.2 does is the "correct" implementation of syntax-rules:

A "literal identifier" is matched as an *identifier* and not a *symbol*.

The library foo.scm defines an identifier 'bar' and lists that under the
literals of the foo-mac macro.  The program demo.scm passes an unbound
identifier 'bar' to the macro, which is not the same identifier as the
one defined in foo.scm, so it doesn't match.  For it to match, foo.scm
would have to export bar, and demo.scm import bar (and not shadow it
with a 'let' or such during the call to foo-mac).

---

This has been bothering me for a long time, because there are a *lot* of
macros in which we really want symbol matching, not identifier matching.
It would be, IMO, awful, if we had to use syntax-case for all of these,
or if we were forced to export all such identifiers and make sure we
don't shadow them at the place we use the macro; sometimes the symbol is
something very short and simple that could easily be shadowed by
accident.  See for instance the 'modify-phases' macro in Guix packages
which uses simple symbols like 'add' or 'delete'.

The least bad thing I can think of is to extend syntax-rules to take
both literal identifiers, and literal symbols.  This could be achieved
in a backwards compatible way like:

  (syntax-rules (lit-id ...) ...)  ->  current semantics
  
  (syntax-rules ((lit-id ...) (lit-sym ...)) ...)
  ->  lit-id are matched as identifiers, lit-sym as symbols

But it feels dirty, and syntax-rules is a well-established standard
Scheme macro so extending it may be questionable.

However, if Guile decides to do this, I could take the time to write an
associated SRFI with the hopes of this practice spreading across the
Scheme community.

Taylan