Lynn and/or Onnie Winebarger wrote: > > > I do not see the possibility of one library redefining another > > > library out of meaningful existence as a feature. > > > > One man's feature is another man's bug. > > I think it is surprising you would embrace this "feature". It means > either the library "variables" are mutable or have a sort of dynamic scope. > By the latter, I mean that if I reference a certain standard library when > writing a library, that's the one that's in lexical scope. > So are library variables really mutable in this fashion in this draft? > If so, it seems inconsistent.
No, library variables are not mutable, and there is no dynamic scope. R6RS libraries are parameters, however. Just as procedures are parameterized by their inputs, libraries and programs are parameterized by the libraries they import. There is no mutation or dynamic scope involved with either kind of parameter. Procedures have contracts that describe their assumptions about the nature of the parameters they accept. Similarly, libraries and programs have contracts that describe their assumptions about the nature of the libraries they import. Most of the draft R6RS and almost all of the libraries document is devoted to descriptions of the assumptions that libraries and programs are allowed to make when they import a standard library. For each such description, there are infinitely many implementations that satisfy it. That means there are infinitely many correct ways in which one implementation of a library may be substituted for another. One purpose of a library system is to allow those substitutions. The draft does not emphasize that purpose, nor does it require implementations to achieve that purpose, but the draft does not preclude implementations that achieve that purpose. Our recent discussion of versions suggests to me that some people believe the R6RS version feature is a way to preclude substitution of libraries. That belief is based on a misunderstanding of what the version feature can accomplish. What the version feature actually accomplishes, in my view, should be avoided like the plague: the version has effectively become part of the name, as in (rnrs base (6)). In order to substitute one implementation of that library for another, which is a legitimate and desirable thing to do, we must give all of those implementations the same name *and* the same version number. A version feature that creates such incentives for proliferation of multiple implementations that all have the same name and version number is a bad idea. That is one of several reasons I have concluded the version feature should be dropped from the report. Will _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
