Re: module trickery

[Marius Vollmer <mvo@zagadka.ping.de>]

tb@becket.net (Thomas Bushnell, BSG) writes:

> Here's a simple failure case with very little trickery.

Yep, it's a real bug somewhere, and I'm afraid it is not easy to fix.

The syncase implementation that we are using assumes that there is a
single toplevel and doesn't really work well with our multiple ones.

What I think is happening is this: in order for syncase to do its job,
properties are placed on symbols.  Since we have multiple global
namespaces, a symbol does not uniquely name a singel macro.  So we put
that property on the variable object that is bound to the symbol in
the current module.  When the property is accessed, we again consult
the variable that is bound to the symbol in the current module.  This
will only work when we find the same variable both times.

However, at the time that print-two is called in your example, the
current module is (test), not (foo).  Since the code in print-two is
expanded lazily, the property lookup will look in the wrong module and
find the wrong (or no) variable.  This makes syncase go into a loop,
for reasons that I don't know.

A workaround is to export all macros along with the procedures that
use them.  This ensures that the same variable is found regardless
what module is current.  (The workaround sucks, of coure, but it
works.)

For your example:

    (define-module (foo)
      :use-syntax (ice-9 syncase)
      :export (whoo!)      ;; <- new

    (define-syntax whoo!
      (syntax-rules ()
        ((_ a b)
         (set! a b))))

    (define-public (print-two)
      (let ((a 0))
        (whoo! a 2)
        (display a)))

    (define-module (test))
    (use-modules (foo))
    (print-two)

If you can export your macros in this way, that would buy you time
until we have a real fix.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel