On 6/26/07, William D Clinger <[EMAIL PROTECTED]> 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)
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
