Thomas Lord wrote: > 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).
I said "general purpose, Turing complete". My point, in case you really missed it, is that there's a distinct lack of general purpose programming languages that use the mechanism that you claimed was "industry best practice". Therefore, it is not industry best practice, in the context of general purpose programming languages. > 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. When representing some external structure in Scheme, it's typical to use the symbol data type to model the names (keywords, identifiers, words, etc.) in that external structure. The canonical example of this is treating Scheme source code as data. In that case, symbols are used to represent identifiers (i.e. names) in the code being operated on. Another relevant example of this is SXML, which represents XML data in this way. One can, of course, represent XML within Scheme using strings, but there are many benefits to using S-expressions and list/symbol structure instead, having to do with Scheme's intrinsic support for the those structures. URIs can certainly be embedded as strings within S-expressions, or even as monolithic symbols or identifiers, but to manipulate them at the component level, the first thing you would need to do is invoke a conversion procedure to turn them into a more usable form. That more usable form would typically at least resemble the library naming system specified by R6RS. Using URIs imposes the need for conversion, which isn't necessary otherwise, and that is an indicator of the sense in which they don't fit in with Scheme's approach to naming or symbolic abstraction. (It would be a little different, btw, if standard Scheme was more polymorphic, and could treat a URI as though it were a list. Although there'd still be an argument against URIs from Scheme aesthetics.) While library names have some external denotation, they also have a meaning within the language, and that meaning has nothing to do with URIs. For example, what purpose does the protocol field of a URI serve, when it appears as a library name in Scheme code? I know the W3C/REST answer to this, but it really isn't relevant to Scheme source code. Using URIs as libary names in Scheme source code represents a conflation of concerns. >> 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. Is a reader extension needed? PLT Scheme has libraries which support reading Java code and manipulating the resulting ASTs. But that doesn't make Java syntax part of the Scheme language. Having a way to read URIs is distinct from specifying URIs as a basic way to name certain entities within the Scheme language. > 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. Common sense suggests no such thing. It does suggest to me that more specific and substantive arguments are lacking, though. The claim about best practice is empty at best, until a relevant example is cited. Besides, it would be necessary to have a mapping from URIs to the actual, non-globally-unique libraries which they denote. There's no advantage to having that mapping be from URIs to that external referent, as opposed to from an S-expression. It's also straightforward to define a mapping from an S-expression to a URI if needed, and I'm sure that'll be done at some point. > 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. How so? Such tools in other languages have to, at minimum, deal with S-exps to some extent even to get to the library names. So what's so monumentally hard? And why should Scheme's design be skewed towards having its source be processed by other languages, at the expense of its own norms? > 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. Such a parser indeed makes a useful library function, and many implementations offer one. > 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. Aside from the point that they'd need to be able to minimally parse S-expressions anyway, I see no reason why Scheme's design should be influenced by such considerations. The S-exp format has proven so useful that people implement it for native use in other languages, such as C and OCaml. Let them eat S-expressions. > The design principle I think should be emphasized here is something like > "Situationally Appropriate Consonance" Oh, I agree. In the case of Scheme source code, it's clear that embedding URIs to represent library names is not situationally appropriate, and is not any kind of consonance. Again, the same appears to be true of all other general purpose, Turing-complete languages. > and the many uses for > externalized library names suggest that URIs are by far the most > parsimonious choice. Redundantly repeating a protocol every time I name a Scheme library does not strike me as parsimonious. > 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. I'm not saying it's normative, but it's meaningful, and it's been out there for years for feedback and discussion. > 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!). Do you really believe that the lack of a fully formal specification here is going to be a problem for the very first incarnation of a standard libary system for Scheme? > I can't make sense of that. Java is observably not the product of a > single organization. ... > So, really, > there isn't a single point in your claim there that I can accept. The Java Language Specification was put out and long controlled by Sun Microsystems, Inc. I'm not making any judgements about that, but it has led to Java being in a very different situation than Scheme. Another huge factor is that the Java specification also included a portable bytecode format, which goes a long way towards reducing divergence between implementations. That alone can explain much of the difference between Scheme and Java standardization. > 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? They are not my priorities, or even the editors' priorities. See the documents I referenced, going back to the charter produced by the Strategy Committee in 2004. The formation of those priorities has been based on a great deal of community discussion going back years before 2004. Arguably, going back to at least 1991, by which time the attempts to standardize a record system for R4RS had failed. It's wonderful that we're now at a point where standardization is going so well that we can argue about whether Scheme should be pioneering a new approach for library naming in the source code of general-purpose languages. But it does make sense to me to first settle on some more basic features before worrying about what really are incredible luxuries, compared to where Scheme standardization has been at. URI library names allegedly solve a problem that Scheme can, right now, only wish it had. And it's a problem that every other general purpose language seems to be able to live with. That's why this is not an R6RS issue. > (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.) I don't know about any totemic struggles. I was just trying to expand on a technical rationale that I thought was being misunderstood. >>> 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? That's very different from "conservatively coded bundles of ... source code files". The draft already specifies what's needed for those to work. But system images? What's the goal, considering that Schemes vary so dramatically in their implementation styles? Anton _______________________________________________ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
