On 12 Oct 2009, at 5:23 am, John Cowan wrote: > The feature-groups list specifies the feature groups which this > implementation must provide in order for the module to work. This is > an extension to R6RS, which does not have feature groups. If the > implementation cannot load the feature groups dynamically, it must > fail to define the module. (Why aren't feature groups just modules? > Because they don't define separate namespaces, and because they mostly > reflect the limitations of particular small Scheme systems rather than > components that can be loaded into them.)
I think feature groups *can* be modules. Yes, ones that are a bunch of names (like binary I/O) can just be modules, for a start; and even ones that just explain implementation limitations (complex numbers etc) can be 'empty modules' with no exported symbols - but, nevertheless, provided on implementations that support the feature set, and not provided on implementations that don't, so software that needs that feature set, when run on an implementation that lacks it, will fail with an error that "complex-numbers" or whatever isn't available. > Module names, like feature groups, are recognized by cond-expand (from > SRFI 0), which makes it possible to conditionally control the actions > of a program depending on what modules have been imported into it. How do you handle conditional imports based on availability of modules? Eg, "if we have opengl libraries, use them, otherwise do our own slow software rendering". It's possible to live without, and tell the user to import the opengl or software versions of your library, but it does lead to any libraries that use your library needing two versions (differing only on the import), all the way up to the app - and if a library has N dependencies each with M options, well, we all know what'll happen: M^N versions of the library! So could cond-expand be available in the module header, too, choosing based on the *availability* of modules rather than whether they're imported? Or is that too much overloading? Should there be a specific way of importing a module but not aborting the import if it's not available? > Other than as specified here, the provisions of R6RS section 7.1 > apply. > Since there are no macros except syntax-rules macros, implicit phasing > is sufficient. What, if anything, to do about version numbers on > modules > remains an open issue: I don't believe they are necessary for small > Scheme. I concur ABS -- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/archives/author/alaric/ _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
