Thomas Lord wrote: > 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.
Those are all XML-related languages, for which URIs make eminent sense. I don't believe that the lack of general-purpose, Turing-complete languages which uses URIs for this purpose is a historical accident. The R6RS is not rejecting any relevant "industry best practices" here. > I see no reason to not use them > unless that reason is "Not Invented Here." No, the reason I've already alluded to is that URIs don't fit in with Scheme's approach to naming or symbolic abstraction. That's very different than "not invented here". > If library names are URIs then it will no longer be a foreign format, > will it? Well, we could specify the syntax of Java as being Scheme syntax, and then it would no longer be a foreign syntax, would it? But somehow that doesn't make such a course of action any more appropriate. (See the discussion about square brackets...) > 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). It's quite possible that there is information missing from the rationale. For example, one rationale for the inability to generate library headers with macros is to support the ability to support processing by relatively simple external tools, which don't have to perform macro expansion in order to determine a library's dependencies. Such tools, if written in Scheme, would have various reasons to parse library names. > 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". The editors and steering committee have been fairly explicit about the scope of the report, as documented in the various charters, progress reports, and status reports, going back to January 2004: http://schemers.org/Documents/Standards/Charter/ Expanding the scope now doesn't make a lot of sense, particularly since the scope has already been contracted in various ways in response to community feedback. > 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. R6RS defines such an environment. Is it that doesn't do so formally enough for you? > 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. How does this differ from what R6RS already specifies? Is it just that you're concerned about potential portability problems introduced by configuration management issues? Either way, an example would help. > 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. As exciting as that possibility is, it must be recognized that not all of the Scheme community is primarily concerned with proactively leveraging the relevant synergies. > 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. Java is an example of a language that has, from the beginning, been driven by a single organization, with primarily commercial goals. Although that process has opened up more recently, it still does not have to deal with a set of incompatible implementations which each have some claim of their own to defining the nature of the Java language. That's worth keeping in mind when discussing the scope of R6RS. In any case, many of the relevant issues here are quite orthogonal to the base language definition, and could be developed as SRFIs initially. In the case of URIs, a SRFI which describes a mapping between R6RS library names and URIs could be useful, and could form the basis for inclusion in R7RS. > 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). That should, in fact, largely apply to a conservatively coded bundle of R6RS Scheme code, particularly if implementations follow the recommendations in the non-normative appendices. Anton _______________________________________________ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
