At Tue, 04 Oct 2005 15:43:00 -0000, Thomas Chust wrote: > > I hope I have put it as simply as possible while still being correct... > These are only the procedures that concern themselves with *loading* of > code, though. In addition there are at least two module systems available > for CHICKEN: The one that comes with the syntax-case egg and the one that > you were using, which comes with the simple-macros egg. These systems have > their own semantics to *import* code and to *separate namespaces*.
This is the important distinction. Chicken lets you choose what symbols are exported from an egg, but they are all exported to the same top-level namespace. This works so long as all exported symbols have different names, but at some point conflicts are unavoidable. This is when you turn to module systems which give you separate namespaces. In both of the above module systems, a module just looks like (module name (exports ...) code ... ) The module form can contain any number of definitions, any of which may be exported, but these are encapsulated and don't show up in the top-level namespace. To access the exports you use IMPORT inside the MODULE form. For example: (module named-arithmetic (plus minus) (define plus +) (define minus -)) (plus 2 2) => Error: unbound variable: plus (module my-module () (import named-arithmetic) (plus 2 2)) => 4 Since you can also define multiple modules within an egg, or in a script or at the REPL, IMPORT has no knowledge of where the modules are defined. If the named-arithmetic module were in an egg, you would first need to load that egg (e.g. via require-extension), and then IMPORT it to see the bindings. I think currently the utf8 egg is the only egg that defines a module which you need to IMPORT. This is because the UTF-8 semantics may be undesirable to load into the top-level, where other eggs may be assuming STRING-REF always returns a value in the range 0-255. All this can be a little confusing for the simple case where you just want to use someone's egg without fussing with module systems. This was part of the motivation for the Common-Scheme module system. It provides yet another loading form IMPORT-EXTENSION, which behaves like REQUIRE-EXTENSION, but also does an IMPORT if the extension happens to be a module. -- Alex _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users