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