Hi Guilers, I'd like to take another stab at getting R6RS library support in, this time by extending the capabilities of the module system. Here's what I've got in mind to start with:
1. Add an optional `version' field to the module record type * What's a good format here? We could mirror the requirements of R6RS here (i.e., (v1 v2 ...) where vx is a whole number) or be more flexible. For example, Apache Maven (I've got Java on the brain from being at work) lets you specify the version of your project however you want, but if you follow the convention its docs set out, it can do things choose the "latest" version or match a version within a range. We could do likewise. 2. Add support for optional version arguments to `use-modules', `resolve-module', etc. * Again, do we want to adhere strictly to R6RS-format version references here or extend their syntax? * Should we establish some rules for what you get when you don't specify a version? Given what we've decided about loading multiple versions of a library (i.e., you can't) and the existing behavior of the module-loading functions (you get an already-loaded module if one's available), conflicts seem possible: E.g., if not specifying a version equates to getting the "first module" in the search path matching the name, then subsequent calls to those functions that *do* specify a version reference may succeed or fail based on the result of a prior call. Regards, Julian
