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 _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
