Re: Need help to understand a macro

[Andreas Rottmann]

Josef Wolf <address@hidden> writes:

> On Fri, Mar 19, 2010 at 05:15:57PM +0100, Andreas Rottmann wrote:
>> defmacros are bound to bite you in the proverbial ass real hard when you
>> combine them with modules, so it's best to avoid them like the
>> plague. At least that's my experience, FWIW.
>
> Thanks for the warning. I'd like to understand why this is dangerous, though.
> Do you have an example for me?
>
Yes, consider the following two modules:

;;---------------8<----------------
(define-module (test a)
  #:export-syntax (test-a)
  #:use-module (srfi srfi-34)
  #:use-module (srfi srfi-35))

(define (funny-condition? c)
  (and (message-condition? c)
       (string-prefix? "FUNNY: " (condition-message c))))

(define-syntax test-a
  (syntax-rules ()
    ((test-a expr)
     (guard (c ((funny-condition? c) 'funny))
       expr))))

(define-module (test b)
  #:use-module (srfi srfi-34)
  #:use-module (srfi srfi-35)
  #:use-module (test a))

(test-a
 (raise (condition (&message (message (string-append "FUNNY: "))))))
;;---------------8<----------------

Now running it causes this:

    WARNING: (test b): imported module (srfi srfi-34) overrides core binding 
`raise'
    Throw to key `unbound-variable':
    ERROR: In procedure module-lookup:
    ERROR: Unbound variable: funny-condition?
    Entering the debugger. Type `bt' for a backtrace or `c' to continue.

Now why doesn't this work, and return 'funny in module B's body? It's
because currently, the `guard' macro from SRFI-34 is implemented with
`define-macro', and it hence throws away (among other things) the
information what `funny-condition?' refers to when being expanded. 

The fully expanded code of the `test-a' form now contains a free
reference to `funny-condition?', while it should have a bound reference
referring to the `funny-condition?' defined in module (test a). 

As you can see, the use of a single defmacro can poison your otherwise
perfectly fine hygienic, referentially transparent, syntax-rules macros.

> Do common-lisp macros suffer from the same problems or is this a scheme
> specific problem?
>
I've just superficial knowledge of CL, but AFAIK, Common Lisp macros
still have similiar issues, but they are (largely) mitigated by the fact
that CL has a function namespace separate from the variable namespace.

> Please note that I am very new to lisp, so please don't beat me if I ask
> dumb questions :-)
>
They were actually very reasonable questions!

Regards, Rotty
-- 
Andreas Rottmann -- <http://rotty.yi.org/>