Hi everyone, (Switching this conversation to guile-devel from guile-user, since it seems more appropriate to this list...)
Alright, so I've been studying the van Tonder and Dybvig-Ghuloum implementations and banging my head against chapter 7 of R6RS, all with an eye towards mapping them onto Guile's module system, and I can't for the life of me figure out why the existing implementations are as complicated as they are. Maybe some more advanced Schemers than I can shed some light on the following: * Import and export levels seem to be a fancy way of notifying the library system of the time at which a library needs to be loaded/evaluated -- that is, if you import something from [library foo] for the "expand phase" of [library bar] you've got to evaluate (i.e., convert to a Guile module) the S-exp for [library foo] before you can evaluate the S-exp for [library bar]. The levels system is simply a numerical way of encapsulating this information, but the proper order of evaluation can also be inferred by inspecting the import- and export-specs of the libraries being loaded -- i.e., if the header of [library bar] specifies an import of anything from [library foo], no matter at what "level," it's a safe move to evaluate [library foo] (if you haven't already done so) before finishing the evaluation of [library bar]. Is that right? * R6RS says that a library's imports need to be visited/instantiated at the time the bindings they export are "referenced." Why? As above, why can't they be visited/instantiated at the time the imports for the importing library are processed? Is there any noticeable difference to the user? Or do you guys read R6RS 7.2 to mean that the side-effects of top-level expressions absolutely need to happen at a time determined by the import level? * R6RS also says that implementations are free to visit/instantiate libraries more or less often than is required by the import-export graph. Why would you want to visit/instantiate a library more than once? Why not just do it once, turn it into a module, and cache it? Andy Wingo noted that some implementations do a fresh visit for every phase (and that it's problematic), but I can't even see why you'd want to if the spec lets you off the hook for it. I understand that the authors of the reference implementation re-created a lot of machinery out of whole cloth since they were avoiding assumptions about features of their target Scheme platforms, but, man, both van Tonder and Dybvig-Ghuloum look like overkill for Guile. Am I missing a major piece of understanding here? Regards, Julian
