On 5/25/07, felix winkelmann <[EMAIL PROTECTED]> wrote:
Modules to be "import"ed by client code should always be available in source code form: the source code is processed by the syntax-case macro expander and binding information (of normal variables and macros) is recorded. So to create an extension, install both the compiled .so and the source files.
Conceivably, a different module-system could be designed that did this processing at compilation time? Perhaps library source would need to be available at application-compilation time, or perhaps the library source could be distilled into an export-directive that contains the details required by the importer (including syntax definitions)? BTW, on a related note, I would love to have an optional, "categorical" namespace through which I could access an extension's definitions, without any concerns of shadowing. E.g. #;1> (use definition-catalogue) ; a theoretical extension #;2> (use url) #;3> url-decode #<procedure (url-decode str124)> #;4> (set! url-decode #f) #;5> url-decode #f #;6> (as-defined-in 'url 'url-decode) #<procedure (url-decode str124)> ...where definition-catalogue's hooks would note the import of (url) and identify any toplevel definitions. The (as-defined-in) procedure performs the lookup of the final definition of 'url-decode that occurred during the extension-load phase. Possibly something like the (oblist) egg could be used to note changes in the toplevel environment caused by the require-extension call, or possibly a formal export-list might be required. (Or a do-not-export list, in the case of volatile definitions that should never be catalogued.) I'm concerned, for example, that more than one egg defines a 'format' procedure, as does the standard library. My app might depend on the standard (format) as well as on your egg; but if you modify your egg to depend on 'format-modular', for example, then my app might break. I'd like to be able to say (as-defined-in 'extras 'format) and know for sure what I'm getting, regardless of import-order and other side-effects. (I'm sure I'd choose a nicer syntax, but the point stands.) Having something like this might eliminate the need for library source to be available in order to make a module system work correctly. (Still not sure how to handle syntax, though.) Thoughts? G _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
