Aaron W. Hsu scripsit: > I would like to make a counter-proposal to your module proposal.
This is just a response to your responses. I'll make a separate response to your counter-proposal when I have digested it. > We might as well use the library word, because this is the word that is > standardized already. I also don't agree with choosing a subset of R6RS > libraries. The two go together. I'm fine with using the keyword "library" if there is indeed to be full backward compatibility, but otherwise not. > The reason I say this is that I don't think the core module system should > be changed by WG2. If it is, then this hampers portability between the two > systems. Portability in the sense of downward compatibility will be quite hampered enough for other reasons. For example, R6RS requires (and I suppose that Thing Two will require also) that all Unicode characters be supported and that something similar to the (rnrs unicode (6)) library be available. Thing One systems, in general, will not meet this requirement and will not have such a library, so Thing Two modules that depend on it are not guaranteed to work in Thing One. On the other hand, if the Thing One module system is a subset (not necessarily a proper one) of Thing Two's, then Thing One modules will work in Thing Two. This satisfies the contravariance restriction I mentioned. > i would prefer to assure implementations that at least, some level > of communication is possible intra-working group here. I don't think > choosing only a subset is going to be good enough in this case. The R6RS > library form is simple enough that I think the WG1 can deal with it. Given that there are people clamoring for R4RS as Thing One and LAMBDA as the module system, that proposal is going to have trouble flying. > I am going to argue that this is a new feature we should not implement in > the standard. We can try it as an experiment somewhere else, but I don't > think such an idea is ready for the standardization process yet, and > because no Scheme system does this currently, I do not have this in my > proposal. Based on this and other arguments, I've replaced feature groups with magic modules (which need a better name). The names exported by magic modules are optional in the core, so importing a magic module that the implementation already supports does nothing. If the implementation cannot support it, an expand-time error results. If the implementation is capable of mutating itself to one that supports the behavior in the magic module, then it does so. As I've said, feature groups / magic modules just make explicit the variability that R5RS and the WG1 charter provide in how a small Scheme implementation may subset the standard while remaining compliant. > Most existing systems allow forward macro references, I suppose you mean most existing module systems rather than most existing R5RS REPLs, which typically don't allow forward references to syntax even in definition forms. (Obviously, forward references to syntax in top-level expression forms makes no sense in a REPL.) > among other things, and a module form will be evaluated as a whole > on the REPL, so there is no need to worry that we won't know for sure > one way or the other. This is a restriction that I don't like. Well, tastes differ. Modules are simplest to implement if the body of the module is treated as if it were simply a begin-body modulo the handling of bound names. > I do suggest that include should be a form, but it should be usable > anywhere. I agree. > I also propose the addition of INCLUDE/CI for case-insensitve > includes. This may not be necessary, but in practice, makdes a > difference with code that doesn't use the #!case-fold specifier > (legacy code that you don't want to change). Presumably you'd also need a corresponding function to correctly import case-sensitive code into a case-insensitive system. > Be careful about the differences in visiting, evaluating, loading, &c. > What if I LOAD the library before hand and it has some side-effects? When > should those side-effects take place? At load time, certainly. > I don't know that we should specify this any more than the R6RS did, > to accomodate people who think that the library should be instantiated > the moment it is loaded, as well as those who think it shold be at > the import time or even the usage time, some of whom may instantiate > it multiple times. R6RS doesn't have LOAD, or any mechanism to load code at run time (though you could write your own LOAD using existing R6RS mechanisms, it might not do quite what you expect). -- John Cowan [email protected] http://ccil.org/~cowan Any sufficiently-complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp. --Greenspun's Tenth Rule of Programming (rules 1-9 are unknown) _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
