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
Received on Tue Jun 26 2007 - 22:26:45 UTC