Anton van Straaten wrote: > Thomas Lord wrote: >> 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.
XSLT is (in a limited way) Turing complete. XQuery is (in a purposeful way) Turing complete (and is defined over data types quite similar to traditional lisp types). HTML acts as a configuration language for programs in other Turing complete languages (e.g. Javascript). As nearly as I can tell, it is also popular to interpret Java class names as URI (e.g., in reflective parts of run-time systems). This is unsurprising, from first principles. Database and other storage and network services are increasingly presented (quite reasonably) with XMLish APIs. It is increasingly accepted that, for the most part, future platforms consist entirely of such APIs. > >> 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". I don't see how URIs "don't fit in with Scheme's approach to naming" -- you'll have to explain that one for me. I'm sure I don't know what you mean by "Scheme's approach to symbolic abstraction" either. > >> 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. It would be very handy, I suspect, to have a Scheme reader extension library which interpreted Java syntax as denoting either syntax trees of a particular sort or as a sequence of calls to constructors. I can see no use for Java syntax in the base library because of the implied redundancies. For example, Java syntax is designed in part as a notation for a kind of procedure for which there is no simple mapping to Scheme lambdas so, what would be the point of Java syntax in the base? In contrast, Scheme currently has no syntax for identifiers which are intended to have significance external to Scheme itself, such as library names. It has no model for such identifiers. Serializability suggests that such identifiers should be recognizable as strings. Common sense and current best practices (and the sound principles behind them) suggest that those strings should contain URIs. > >> 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. At best, you are saying that in order to make it incrementally easier to write such tools in Scheme, we must make it monumentally harder to write or adapt such tools in other languages. A Scheme URI "parser" (in the weak sense that you refer to) for URIs is but a few lines of code and can be vastly useful in many applications that range far afield of handling library source code. In contrast, a PHP "parser" for s-exp-based library names would require implementing significant chunks of a Scheme reader and would have little utility outside of handling Scheme library texts. The design principle I think should be emphasized here is something like "Situationally Appropriate Consonance" and the many uses for externalized library names suggest that URIs are by far the most parsimonious choice. > >> 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. I don't think that the statement of "scope" was intended to be normative in the way you imply. If it was, then it is correspondingly faulty. > >> 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? No, it does not. If the denotational semantics were still in place I would want an ExecEnv category whose structure describes "bag of source files". I guess in an operational semantics I'd want an ExecEnv set or something. More pragmatically, I'd like reflection on ExecEnv, such as getting a list of available source files. Perhaps even a standard API for adding new source files (gasp!). > >> 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. > See above. I'd like the execution environment to be recognized both in the formal semantics and in the APIs. In the APIs, ideally, we can converge on ways to manipulate that environment. >> 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. > Oh, pish posh. Fashions and buzz-words are not meaningless only because they are such. In this case, the fashions and buzz-words are converging on something deep and deeply relevant to programming language design. Execution environments and the concept of a system image have, for decades, been treated as "out of scope" in language standards because there was no pragmatic way to standardize them, not because they aren't relevant. That has been a problem, as when program texts "make no sense" except when understood in the context of some externally supplied execution environment. We are, largely thanks to W3C, getting to a point in time when it is pragmatic for language designers to bring those issues "in scope" and hence relieve the problems. >> 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. > I can't make sense of that. Java is observably not the product of a single organization. It's goals are quite expansive (though, sure, largely commercial -- what isn't? isn't "commercial" a key component of "engineering"?) It's process has been at least somewhat open since pre-alpha days (says the proud owner of an early draft of the "Oak" spec) and, indeed, the organizers of that process (e.g. Gabriel) are some of the world's leading innovators in what "open process" means. Java has had its share of portability problems among implementations (and, its share of successes in progressing past those). So, really, there isn't a single point in your claim there that I can accept. > That's worth keeping in mind when discussing the scope of R6RS. > Uh-huh. > 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. Why is this an R7 issue rather than a contemporary issue? Can we make progress in no other way than if we sequence work according to your priorities? Are your suggested priorities obviously the fastest way to make progress? How did you arrive at these conclusions? (Yet another example of why publishing R6 at all is a bad idea -- it leads to this kind of totemic struggle over names (and hence timing) of efforts.) > >> 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. An interesting thought-experiment or, perhaps, real project: can you specify (perhaps presuming the draft) a SRFI that specifies a commodity form for Scheme-based system images? -t _______________________________________________ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
