[r6rs-discuss] on rational 6.7 Compund library names

From: Thomas Lord <lord>
Date: Tue, 26 Jun 2007 12:56:51 -0700

Anton van Straaten wrote:
> Thomas Lord wrote:
>> This design decision rebels against industry best practices, for no
>> good reason.
>
> Which best practices are you referring to? The reason I ask is that
> it sounds as though you're suggesting using URIs as library names in
> the source code of programs, but most languages don't do that.

Most do not, true, but then most designs for library names pre-date the
definition of the URI namespace and/or the recognition of its
importance. A variety of recent languages all do use URIs as module
names: XSLT, XML Schema, XQuery, and HTML for example.


The rationale takes special pains, elsewhere, to consider external
serialization needs in the design of library syntax. That is the
rationale for a delimited (by parentheses) library syntax.
Serialization considerations also apply to library names. The URI
standards address all of the requirements offered for library names,
have a principled, clean design, and are already handled by many
computing systems. They are, of course, designed with serialization
concerns as one of the primary goals. I see no reason to not use them
unless that reason is "Not Invented Here."



>
> Particularly in the case of Scheme, there are real benefits to having
> library names be easily readable by Scheme programs, without requiring
> that those programs parse what amounts to a foreign serialization format.


If library names are URIs then it will no longer be a foreign format,
will it? And, more to the point, on the issue of version numbers, the
rationale fails to persuade that implementations must *parse* library
names at all (rather than treating them as atomic identifiers).
(Parsing of some sort is surely needed to map library names into file
names, and so forth -- but such parsing is likely to be highly
idiosyncratic to each implementation.)



>
> Note that the 5.91 draft did specify library names as URIs, but
> objections were raised about this, which the editors "became convinced
> by." It might be worth reviewing the list archives to see some of
> those objections, to avoid unnecessary repetition.
>

Well, some repetition is inherent in the objective of my top-level "on
rationale X.Y ...." posts. I do mean to (or mean to not) re-open old
arguments -- only to summarize certain objections that I do not think
have been sufficiently addressed in previous discussions.



> That's not to say that there aren't some valid issues here that are
> not addressed by R6RS. However, many of those issues are really
> outside the scope of the normative part of R6RS. Note that the
> non-normative appendices include some recommendations about mapping of
> library names to resources, although they are not comprehensive.
>

Just speaking informally, as we chat: I think that we can an should be
a lot more aggressive about formalizing those issues you are calling
"outside the scope". We might formally define an "execution
environment" as a thing which (in part) contains a bag of named
libraries, with the invariant that no two libraries in the bag have the
same name. We can then formally say what it means run a program in
that environment, given only knowledge of the source texts of the
libraries and top-level programs it contains. My instinct is that that
would help implementors converge on a very robust kind of portability in
this way: Implementations would still have to have their own ad-hoc
ways to map library names into file systems and so forth, but this
formalization of an "execution environment" would give that mapping
problem a very definite target which, if hit, would mean that "bundles"
of scheme code (a bag of libraries and top-level programs) would have a
deterministic semantics that is true for every conforming implementation
and system configuration. Such deterministic semantics are rare and
precious in real-world programming language definitions and they are
skyrocketing in economic importance as computing platforms become
increasingly commoditized and demand for low-transaction costs in
instantiating new computing systems correspondingly grows.

This is not a small point, I hope you'll agree. Right now, as we write
to one another, there is a huge amount of economic activity around (in
the broadest sense) "virtualization" of computing systems. The overall
goals is that "system images" which specify the behavior of a computing
system should be commodities, and that platform cycles, storage, and
bandwidth to run images should be fungible. So, we're moving from a
world of the "stored program" to a more general world of the "commodity
system image".

Java is an example of a language which has done a good job of leveraging
its language definition to build notations for commodity system
images. That is to say that conservatively coded bundles of Java
source code files have a sufficiently well defined semantics that they
can be exchanged as commodities and executed on generic, virtual,
fungible platforms (e.g., commodity grids).


-t
Received on Tue Jun 26 2007 - 15:56:51 UTC