(Consolidated reply) Peter Bex scripsit:
> What added benefit do feature groups have? If the module cannot be > defined because a feature is not implemented, what happens? Is that > an error? I'm asking because I suppose it would also be an error to > define a module containing references to undefined identifiers. Quite so. However, several feature groups (%bignums, %rationals, %ieee-float) don't bind any identifiers. Also, being allowed to declare feature groups up front allows for fail-fast behavior: you find out when you import the module that it won't work on your Scheme, not when you try to call procedures in it. Alaric Snell-Pym scripsit: > I think feature groups *can* be modules. Absolutely. However, I don't think they *should* be. Feature groups aren't added stuff that your implementation may provide, they are profiles (standardized subsets) of the Standard. Many standards provide such profiles, and they just formalize the notion already present in R4RS and R5RS that some stuff can be left out, as explained in the section on the numeric tower and by the occasional occurrence of "optional procedure". (Technically, it's a *set* of feature groups that constitutes a profile.) Making a feature group into a module is just extra work for programmers, who then have to import the module all the time, and extra bureaucracy for standardizers. I'll have to think further on the interaction between cond-expand and modules. My current notion is that cond-expand at top level should be able to expand into an import, since import at top level is just ordinary syntax. However, I'm reluctant to completely cast aside R6RS compatibility inside a module by treating imports as ordinary binding forms there as well. -- The first thing you learn in a lawin' family John Cowan is that there ain't no definite answers [email protected] to anything. --Calpurnia in To Kill A Mockingbird _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
