[r6rs-discuss] on rational 6.7 Compund library names

From: Anton van Straaten <anton>
Date: Wed, 27 Jun 2007 06:21:36 -0400

Thomas Lord wrote:
> You ignored my point; I did not miss yours.

I didn't intentionally ignore anything, but I may have not understood.

> URIs are "industry best
> practice" for externalizable, lightly-structured, distributed-allocation
> names. The need for such names arises in many languages but few
> languages besides Scheme have the privilege of defining such a namespace
> in the historic context of URIs-as-best-practice.

Hmmm... Python 3000 has a shot at it. Or Perl 6. So does ECMAScript 4.
  The latter, of course, being so at home inside web browsers, might
have a real reason to do it. In this area, there's nothing wrong with
Scheme being a smidgen conservative.

> Hardly. Quite the opposite. As the popular interfaces for opening
> files illustrate, it is quite common to use *strings* for external
> names.

Library names are not just external names, as you've acknowledged.
They're certainly not file names, although a mapping to file names might
often need to exist.

> Identifiers are used for matters internal to programs, such as variable
> names.

Identifiers, or more generally, names, are used for matters internal to
the domain being modeled. The domain here is libraries, and R6RS
represents their names naturally, for Scheme.

>> 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.
>
>
> I am having trouble making sense of you there but I think you are
> confusing surface syntax with logical structure and with internal
> representation.

I mentioned both S-expressions and list/symbol structure to try to
communicate that both are relevant here.

> XML has its native surface syntaxes and sometimes those are very
> convenient. It would even be convenient to mix such surface syntaxes
> into Scheme source. It is also sometimes very convenient to use a
> surface syntax for XML that is derived from Scheme's syntactic
> datums. I think we agree about that much, no?
>
> Of course, in the preferred API at run-time, XMLish datums ought to have
> APIs whose logical structure follows the DOM definition, at least
> insofar as we want to manipulate those datums with procedures that enjoy
> closure properties over the domain of XML datums.
>
> And, yes, lists and symbols are likely suspects when it comes time to
> pick a run-time representation of those XMLish datums.
>
> What of all this? I don't see how it makes any point that would lead
> you to argue with me.

The same reasons that make it "very convenient" to use S-expression
syntax to represent XML in Scheme, apply to library names.

> Instead, you ought to embrace and explore canonicalizing XMLish types
> and APIs within Scheme for many of the same reasons that there is
> justified enthusiasm about canonicalizing Unicode types and APIs.

Sure. See SXML etc. That doesn't automatically translate to using URIs
for library names.

>> 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 is true. The reason that such rules are defined separately from,
> say, the rules for cons pairs and symbols, is because of the added
> constraints of global utility, serializability, and distributed
> allocation. When you are talking about names for variables that occur
> only within some textually bounded lexical scope, the design constraints
> are one way -- when you are talking about names for entities that will
> be exchanged as commodities among members of a globally distributed and
> decentralized population, the design constraints are another thing.

Sure. So let's look at Java, which addressed this issue by mapping
library names to the domain name system plus a tree of names: the result
can be mapped to a URI, certainly, but is not as general as a URI. What
do you feel Java has lost by this approach? What would it gain by
switching to URIs in Java source?

> URIs are not lists. They just aren't. So, it is nonsense to talk
> about treating a URI as if it were a list. You are just thinking
> wishfully.

No, I'm thinking in terms of the needs of Scheme's library names, not in
terms of some broader, but irrelevant, problem. It might be interesting
to examine the ways in which URIs are not lists, and see how closely
that corresponds to the ways in which they're overkill for library names
in Scheme.

> Yes, that's right, there are both internal and external constraints to
> satisfy simultaneously. That is part of what makes it a non-trivial
> engineering problem.

Actually, it is trivial. Define a naming system that makes sense within
Scheme, and then define a mapping from those names to URIs.

> The "protocol field" (really called the "method" -- examples are
> "http:", "ftp:", "mailto:", and "urn:")

If we're being pedantic, that's actually called the "scheme". "Method"
is an HTTP thing.

BTW, in the R6RS Library SRFI (83), the scheme's name was "scheme".
Probably lucky we didn't try to register that.

> We would like programmers all around the world to be able to publish
> named Scheme libraries on an equal footing with one another, no? That
> is, we do not wish them to have to appeal to a central authority to be
> assigned a library name, yet we would like all separately published
> libraries to have distinct names, right? The URI structure of method
> and authority fields achieves those goals in a very pragmatic way.

Take a look at Appendix E in the R6RS Non-Normative Appendices.

> What conflation? We would, ideally, like all published libraries to be
> fully compositional, at least among libraries published by non-malicious
> parties. That requires a distributed allocation strategy and you won't
> come up with a good mechanism for that until you either adopt or
> re-invent the URI method-plus-authority structure.

Or specify the appropriate subset of it.

> The main area where people wrestle over externalizable identifiers is in
> network protocols and, these days, if you aren't using URIs for your
> application-independent identifiers, you need to provide a positive
> rationale.

I don't see that this relates to library names within Scheme source.

> There is considerable advantage. For example, many database systems
> have excellent, richly detailed, highly accurate support for treating
> URIs as database keys -- such as might be used to map from a library
> name to the contextually appropriate source text.
>
> I don't know of any serious database that uses Scheme s-exps as primary
> keys.

So serialize to a URI when writing to the database, if you like. We
don't encode all Scheme source as ASN.1 in case we need to send it over
a network at some point.

> The library syntax of the draft is carefully and explicitly designed so
> that the extent to which tools must understand s-exp syntax is severely
> minimized. It wanders, aimlessly, away from design pattern when it
> introduces library names which are syntactic (recursive) lists of Scheme
> identifiers and syntactic numbers.

That may be a valid concern. There are a variety of possible solutions
to that.

>> And why should Scheme's design be skewed towards having its source be
>> processed by other languages, at the expense of its own norms?
>
>
> Because Scheme is an engineering project, among other things. It
> exists within a larger world.

There are many, many ways in which Scheme could make its existence in
that larger world much easier, if that were a priority. I think it's
hard to justify putting URI library names in the source code high on
that list.

>> Redundantly repeating a protocol every time I name a Scheme library
>> does not strike me as parsimonious.
>
>
>
> Then introduce a semantic model of dynamic context when library sources
> are processed and permit relative URIs. That is the pattern commonly
> applied in response to such a design constraint.

Good idea. Maybe take that a step further and only specify the parts of
the URI we need, and represent them using a syntax appropriate for Scheme.

> And here we are, enjoying feedback and discussion. This is no small
> part of the problem with the very idea of continuing the revised report
> series: the transaction costs for each new revision apparently must
> include a multi-year process. That is no way to evolve a language.

Which language evolution models do you consider more suitable?

>> 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.
>>
>
>
> Please, whatever you do, just throw around lots of vague innuendo
> combined with vacuous truisms.

I was trying not to waste too much more time than I already have on
this. No innuendo intended, your response to me raised issues about
Java's openness etc., and I'm saying I'm not commenting on that, I
honestly don't care about it. The point is that raising Java as a model
for a portable language specification, as you originally did, is not
very relevant to where Scheme stands today, because of major differences
between the two situations. If you consider the reasons for that to be
truisms, then I don't understand your point in raising the example.

>> 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.
>
>
> A bold claim and perhaps a launching point for polemic but, really, I
> don't think you are saying anything serious there.

A prescribed bytecode format is a significant constraint on
implementations. It inserts a large set of detailed requirements right
in the middle of an implementation, between the front end (compiler) and
the back end (VM). Combined with the language specification itself,
which imposes requirements at both ends, it makes for a much more
stringent specification framework.

>> I don't know about any totemic struggles.
>
>
> Above, you made a claim about what is and what is not "an R6RS issue".
> That is an example. What an utterly pointless and unproductive
> question it should be whether or not something is "an R6RS issue" yet,
> here we are going on about it.

R6RS is the name of the project to which this mailing list is devoted,
and that project has some goals and so on. It'd be kind of hard to
discuss it without mentioning its name. Sometimes a name is just a name.

>> I was just trying to expand on a technical rationale that I thought
>> was being misunderstood.
>
>
> A lot of crap in politics function in just the way you are demonstrating
> here. There's this vague, made-up, highly problematic epistomological
> concept of "an R6RS issue" and in your statement there you are
> conflating that very messed up concept with a technical rationale.

I started out simply trying to expand on a technical rationale, but made
the apparent mistake of getting involved in a broader discussion. The
real lesson from politics here is that politicians have good reasons for
learning to stay on message.

I could perhaps learn from the example of repeatedly raising questions
about the epistemological foundation of R6RS.

> Why can't a conservatively coded bundle of source code files be a system
> image?

I've never heard the term used that way, and I didn't know what you had
in mind. See Appendix D in the R6RS Non-Normative Appendices. It's
low-tech, but not that far from such an "image".

Anton
Received on Wed Jun 27 2007 - 06:21:36 UTC