Hi Andy, Thanks so much for helping me parse!
> I think you're right, yes. I think that the approach that you describe > has been called "Implicit phasing" by Ghuloum and Dybvig. They have a > paper about it, "Implicit phasing in R6RS libraries" -- but I haven't > been able to find it freely on the web. ACM fail. Oooh -- if you do find it, let me know. That sounds interesting. > I could not find the quote that you referred to here -- I think what I > can tell (from 7.2): (Yes, that was the bit I was referring to. Sorry about that.) One thing that occurred to me, though, while I was brooding on this, is the case in which you've got two bindings that share the same name that are both imported (from different libraries) into library foo -- one's a syntax transformer used to expand library foo, the other's a function used by library foo at runtime. R6RS seems designed to address cases like this so that they work out, you know, hygienically. And I think Guile's module system can handle this as well, though it may require some slightly weird designs. E.g., one thing I was thinking of trying was mapping an R6RS library onto *two* generated Guile modules: One to represent the expansion environment, and one to represent the environment of the expanded library in which the library bindings and top-level expressions are actually evaluated (I guess this is the same as the runtime environment?). The first module's imports would include bindings required for expansion; the second's would include the stuff for runtime. > I don't think you're missing anything big, no. I hadn't fully poked into > these implementations -- if it is easier just to build something on top > of Guile's modules than to retrofit guile's modules into one of their > implementations, then that's all the better, right? Strongly agree. Regards, Julian