[r6rs-discuss] libraries are parameters (was set-car!)

From: William D Clinger <will>
Date: Tue, 26 Jun 2007 12:25:43 -0400

Lynn and/or Onnie Winebarger wrote:

> On the one hand, the draft reads as though their should be no semantic
> distinction between pre-compiled libraries and libraries appearing in source
> form. It would also appear, to a naive reader such as myself, that a
> precompiled library would use the import libraries in effect at the time of
> compilation, making the library "parameters" into "bindings". I certainly
> see no _explicit_ suggestion that import parameters should be regarded as
> parameters to be resolved at the time of top-level compilation rather than
> bindings resolved at the time of library compilation. It could be there
> explicitly and I have simply missed it, or it could be there implictly
> (intentionally) and I have not made the deduction, or it could be an
> unintended implicit consequence and you are pointing it out.

That libraries are (compile-time) parameters is implicit
and at least partly intentional. I do not know whether
the implicitness was intentional.

> In some sense, I would think that, in the absence of an explicit
> library form to the contrary, the name of a standard library should be
> understood to scope to the meaning specified in the standard, and the
> failure of an implementation to map the library to a matching meaning should
> be regarded as a failure of the implementation, not a matter of freedom in
> how to map library names to file names.

One problem with what you say above is that the name of
a standard library must somehow be mapped to a concrete
thing that satisfies the specification set forth within
the standard. That concrete thing is the denotation of
the library name. It is a mistake to think of the API
described in the standard as the denotation of a library
name; at the very least, libraries must be compatible at
the level of an ABI.

> For all non-standard libraries,
> Will's observation about the indefiniteness of mapping library names to the
> file system seems accurate.

It applies to the standard libraries as well. This is
easily overlooked, and I think some of the editors may
have overlooked it at times.

If the R6RS is anything other than a complete flop, then
there will be multiple implementations of all standard
libraries. With the current draft R6RS, these multiple
implementations would all have to have the same name
*and* the same version, but most of them would be wildly
incompatible.

For example, I doubt very much whether MzScheme's (rnrs
base (6)) library will compatible with Larceny's, even
though they would have exactly the same name and version.
Someone might construct an implementation of the R6RS in
which the (rnrs base (6)) library isn't even written in
Scheme.

In Larceny, there will be many incompatible versions of
(rnrs base (6)), all with exactly the same name and version.
The choice between them will be made on the basis of which
variety of Larceny is being used (native, Petit, Common),
the target architecture (Sparc, x86-32 MacOS, x86-32 Linux,
x86-32 Windows, PowerPC MacOS, other Unix, CLR, Mono, etc,
with 64-bit versions of all the above on their way), the
garbage collector, whether (rnrs mutable-pairs (6)) is
imported by any part of the program, the conformance mode,
and the safety mode.

With the current draft R6RS, to think there is only one
library with a given name and version is sheer madness.

Will
Received on Tue Jun 26 2007 - 12:25:43 UTC