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

From: William D Clinger <will>
Date: Sat, 23 Jun 2007 08:58:26 -0400

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
Received on Sat Jun 23 2007 - 08:58:26 UTC