The subject might sound weird, but I couldn't find any better name. So please bare with it.
Problem
Suppose you have a situation that 2 macros need to refer the same implicitly bound variable. For example, consider
define-generic and
define-method; the declaration of generic function is done by
define-generic, and adding definition to it is done by
define-method. Now, you want to write it as simple as possible, so you've decided to use implicitly bound hashtable.
;; naive definition of define-generic (doesn't work)
(define-syntax define-generic-naive
(syntax-rules ()
((_ name)
(begin
(define implicit (make-eq-hashtable))
(define (name . args)
;; lookup and execute
)))))
(define-syntax define-method-naive
(syntax-rules ()
((_ name formals body ...)
(begin
(define (real-proc . formals) body ...)
(define dummy
;; oops, implicit can't be referred here!
(hashtable-set! implicit 'name real-proc))))))
Now, your task is make this happen somewhat.
Passing explicitly
Taking this path isn't really what I want, but it's the only way to do it on R7RS.
(define-syntax define-generic-explicit
(syntax-rules ()
((_ name table)
(begin
(define table (make-eq-hashtable))
(define (name . args)
;; lookup and execute
)))))
(define-syntax define-method-naive
(syntax-rules ()
((_ name table formals body ...)
(begin
(define (real-proc . formals) body ...)
(define dummy
(hashtable-set! table 'name real-proc))))))
The problem with this implementation is that you need to know the name of the shared bindings. It might be good for debugging or breaking, but you probably don't want to care about something only used internally.
Macro generating macro
If 2 macros cannot refer the variable defined in one of the macro, then make it in the one macro like this:
(define-syntax define-generic/defmethod
(syntax-rules ()
((_ name method-name)
(begin
(define shared (make-eq-hashtable))
(define (name . args)
;; lookup and execute
)
(define-syntax method-name
(syntax-rules ()
((_ name shared formals body (... ...))
(begin
(define (real-proc . formals) body (... ...))
(define dummy
(hashtable-set! shared 'name real-proc))))))))))
It's probably better than explicitly passing, but it's rather ugly. The method definition should be more generic. In this implementation, the method definition belongs to specific generic function definition.
Identifier macro
If you are using R6RS, then
syntax-case can handle non list macro (not sure how it should be called, but I say identifier macro). So if the name of generic function itself can be evaluated to implicit definition name, then we can share the binding by referring the name.
(define-syntax define-generic
(syntax-rules ()
((_ name shared)
(begin
(define shared (make-eq-hashtable))
(define (real-proc . args)
;; lookup
)
(define-syntax name
(lambda (x)
(syntax-case x ()
((_ args (... ...)) #'(real-proc args (... ...)))
(k (identifier? #'k) #'shared))))))))
(define-syntax define-method
(syntax-rules ()
((_ name formals body ...)
(begin
(define (real . formals) body ...)
;; method name should generic function name;
;; thus, it's an identifier macro to return
;; implicit table name.
(define dummy (hashtable-set! name 'name real))))))
Better, at least for me. If I see it with half eye closed, then it looks like fake LISP-2.
Pitfalls I've got
I first thought that maybe I can use
datum->syntax to create the same name; however, this wasn't a good idea. It is okay to if both generic function declaration and method definitions are in the same library; otherwise, you'd get a problem. Suppose you have a library
(a) contains only
define-generic and other library
(b) contains
define-method. Now, which template identifier you should use to generate the same name of the implicit binding? You need to use the identifier
define-generic in the library
(a), and it's impossible to use it in library
(b). (This is the reason why I needed to write the version 2, macro generating macro.)
Conclusion
I don't have any intention to say, macro is the best, or something like that, but if something beyond procedure (in this case, emulating LISP-2, kind of), then it is rather necessary feature.