[bug #31472] Probable psyntax bug with multiple defininitions in the macro expansion

[Andy Wingo]

Follow-up Comment #1, bug #31472 (project guile):

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

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?31472>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/