On 6/26/07, William D Clinger <will at ccs.neu.edu> wrote:
>
> 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.
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.
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?
> 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.
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. 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!
Maybe this is your point, or a relative thereof?
> 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.
On a binary level, yes, but that is irrelevant. If you mean that
running any R6RS program on two implementations will have different meanings
(in terms of the R6RS objects produced, not the concrete instantiations of
them), then either one or both of the implementations will be defective or
R6RS will be a flop by virtue of being meaningless.
Lynn (sorry for the name confusion)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.r6rs.org/pipermail/r6rs-discuss/attachments/20070626/73e2c814/attachment-0001.htm
Received on Tue Jun 26 2007 - 15:28:31 UTC