[r6rs-discuss] on rational 6.7 Compund library names

From: Anton van Straaten <anton>
Date: Wed, 27 Jun 2007 02:09:13 -0400

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
Received on Wed Jun 27 2007 - 02:09:13 UTC