31.12 Module System Quirks

Although the programming interfaces are relatively stable, the Guile module system itself is still evolving. Here are some situations where usage surpasses design.

• When using a module which exports a macro definition, the other module must export all bindings the macro expansion uses, too, because the expanded code would otherwise not be able to see these definitions and issue a “variable unbound” error, or worse, would use another binding which might be present in the scope of the expansion.
• When two or more used modules export bindings with the same names, the last accessed module wins, and the exported binding of that last module will silently be used. This might lead to hard-to-find errors because wrong procedures or variables are used. To avoid this kind of name-clash situation, use a custom interface specification (see Using Guile Modules). (We include this entry for the possible benefit of users of Guile versions previous to 1.4.2, when custom interfaces were added to the module system.)
• [Add other quirks here.]