On Thu, Sep 10, 2009 at 4:31 PM, John Cowan <[email protected]> wrote: > > Alaric Snell-Pym scripsit: > > > Even if just a recommendation that an implementation > > supply an "install-module" procedure that takes a filename, and > > attempts to find a module inside it and install it, or something. > > I wouldn't want to see that as a *Scheme* procedure, but if you mean that > the implementation should provide it somehow (possibly outside Scheme -- > arbitrary programs probably shouldn't install things, and may not have > the privileges to do so anyhow), then fair enough.
This aversion is something I can't understand. The most obvious, effective, and system-agnostic way of handling this is precisely to make available 3 *Scheme* procedures: (inter-library <filename or URI type argument>) (disinter-library library-name) (serialize-library library-name) Here I use "library-name" for whatever data structure is used to specify library names, such as the lists of symbols in R6RS. How the Scheme implementation deals with a multi-user implementation is definitely an issue to ignore in the standard, and something the user should not have to learn. They could save it in a file system tree, or in a relational database, or by printing out the source in a little room with a person who types it back in whenever the library is imported - there is no need to force the user to learn these details. Scheme programs do not live in a vacuum, they exist in the Scheme system. Other languages have this property as well, and many of them leave their programmers to deal with the messy intersection of the operating system and the particular implementation of the programming language. What does it profit the scheme user for the standard to stick its head in the sand about the reality that their programs exist in a stateful environment? Is this about being a "language" and not a "system"? If there's some other reason for this separation, please enlighten me. If it would help make a case, these thee operators could be considered reflective programming constructions. Lynn _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
