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

From: William D Clinger <will>
Date: Tue, 26 Jun 2007 19:06:21 -0400

Lynn Winebarger wrote:
> By compile-time I take it you mean the compile-time of the top-level
> program rather than the library as a stand-alone object.

Yes, you may assume I meant the compile time of the
top-level program. The current draft allows (but does
not require) separate compilation, so the libraries
might be compiled ahead of time, but this has no
bearing on our discussion. For simplicity, we may
assume that the top-level program and all its libraries
are always compiled at the same time.

> The only reason I can see for this assertion being implied is the
> insistence on the "single-instantiation rule" for libraries (the root of
> "multiple versions of a library not allowed"). But this could be
> interpreted as merely forbidding the compilation of an aggregate rather than
> prescribing a parameterization of the pre-compiled libraries. Is there
> something else at work here?

Yes.

By "this assertion", you mean my assertion that
libraries are compile-time parameters to the top-level
program and also to other libraries that depend upon
them.

That is implied by the portability goal. If your
top-level program is to work in both HerrScheme and
Klepto, then it follows that your top-level program
is parameterized to work with the wildly different
versions of (rnrs base (6)) provided by HerrScheme
and Klepto.

> While that concrete thing may be viewed as _a_ denotation of the
> name, it surely must not be judged as _the_ denotation of the name.

That concrete thing (the imported library) bears the
same relationship to the name used to refer to it in
the importing program that an actual parameter bears
to the formal parameter of a lambda expression.

When discussing (lambda (x) (+ x 1)), we do not say
13 is _the_ denotation of x. You (not I) raised the
subject of denotational semantics, which I happen to
understand fairly well. In denotational semantics,
the denotation of x is a function from environments
to stores to expression continuations to answers, or
something like that. In like manner, the denotation
of a library is an extremely complex higher-order
thing, much hairier than the denotation of x.

Informally, however, we tend to speak as though the
variable x directly denotes whatever L-value or
(more usually) R-value it happens to "name" at some
moment in the computation. With this informal mode
of speaking, x has no denotation at all until the
procedure that results from the lambda expression
is applied to an argument. However, when discussing

    ((lambda (x) (+ x 1)) 13)

informally, it is quite proper to refer to 13 as the
denotation of x.

In like manner, when speaking informally, as we were,
the name (rnrs base (6)) has no informal denotation
until a concrete thing is supplied as parameter to the
top-level program or library that imports (rnrs base (6)).

> By
> creating a document called a "standard", a reasonable person would conclude
> that there is _some_ intended (though perhaps inconsistent!) denotational
> semantics through which any implementation should be expected to factor.
> The well-specified-ness/consistency of that semantics may be in some doubt,
> but failure even to intend something in this regard should disqualify the
> document from being a "standard". If there is no intended semantics
> whatsoever (even where the English has a plain meaning), then there is no
> way to judge correctness of an implementation - all is permissible!

No. The specification of + describes the kinds of
arguments it accepts, and specifies its behavior
on those arguments (with some leeway for inexact
arguments). Similarly, a top-level program or
library that imports (rnrs base (6)) is specifying
the names it expects that library to supply, and
the behavior of those names. Those expections are
spelled out in the draft's specification of the
(rnrs base (6)) library.

An extremely important part of that specification
that is only implicit in the draft R6RS is that all
of the standard libraries are consistent. For
example, HerrScheme's (rnrs base (6)) library is
consistent with HerrScheme's (rnrs lists (6))
library, and Klepto's (rnrs base (6)) library is
consistent with Klepto's (rnrs lists (6)) library,
but all bets are off if you try to run your program
with HerrScheme's (rnrs base (6)) library and
Klepto's (rnrs lists (6)) library. Implementors
understand that it is their responsibility to keep
you from doing that by accident, but you might be
able to do it on purpose in some systems. That
would be like passing a symbol as an argument to
+ to see what would happen.

The above, of course, is already a simplification.
Klepto might have three dozen different versions
of its (rnrs base (6)) library, with another dozen
versions of its (rnrs lists (6)) library, so the
consistency issue arises even within a single
implementation. Again, implementors worry about
this so you won't have to.

> > 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.
>
> On a binary level, yes, but that is irrelevant.

No, I was talking about different versions at the
source level.

This might be easier for you to understand if you
think about the (r6rs io ports (6)) library. If
you think about it, you will see why the source code
for native-eol-style and native-transcoder are likely
to depend upon your operating system. There are all
sorts of other dependencies that might be harder for
you to understand: the codecs, all of the code that
does file i/o or standard input or output, and so on
are likely to depend on the target system, even in a
single implementation such as Klepto.

It may be even harder for you to understand that the
source code for cons depends upon the allocator, which
depends in turn upon the target architecture, operating
system, garbage collector, and various other things
that you should just trust the implementors to get
right. If they do (and they will), and you stick to
the standard libraries, and to libraries that can be
written using the standard libraries, then you can
probably forget about the fact that even the standard
libraries are parameters.

That doesn't mean it isn't true. It just means you
won't have to be aware of it.

Will
Received on Tue Jun 26 2007 - 19:06:21 UTC