Sun 27 Feb 2011 12:33:49 PM UTC, comment #1:
Hi Andreas,
I have thought about this one a fair amount this weekend. The issues are twofold. One, as you note, the modules are getting resolved wrongly -- the expansion makes the procedure scope "t" in the macro's module, not the expansion module. The question is, what should happen?
According to all the hygiene folk I hear from, the (define t #(1 2 3)) shouldn't actually create a binding for "t" in any module.
A simpler case is the following:
(define-syntax define-x
(syntax-rules ()
((_) (define x 0))))
The issue is, what should happen when you (define-x) ? Should you later -- in the REPL, say -- be able to access a binding named "x" in the current module?
Hygiene people say no. Hygiene people say that since the identifier "x" was introduced by the macro, it should be visible only within the macro --- and since it's not used elsewhere in the macro, effectively it's invisible. Though you can't really know its extent of course. And, in Guile, if we were to gensym a name for it -- a wild thing to think about doing, serializing a useless (define x_21234113132 0) into a .go file -- it would still take up "space" in the module (and the .go file), every time you (define-x) you would be adding useless, inaccessible bindings to your image. It doesn't seem like a great idea.
So, unless I misunderstand the issues or am overlooking a solution, I think that Guile will continue to bind "t" in the expanding module, as indeed happens in this macro.
The second problem thus "resolved", we need to make the procedure in the expansion scope its "t" according to the "t" it introduces. This only happens when expanding a toplevel sequence -- chi-top-sequence, in psyntax.scm. I have recently refactored that procedure to be able to know what bindings it introduces before going to expand the expressions. So your mission, should you choose to accept it, is to distructively mutate the toplevel ribcage before going in to expand the sub-expressions in chi-top-sequence.
Good luck!
Andy
|