/Btw doesn't the authority field contain a hostname which either
should be ignored or make us dependent on a central registry?/
No. The authority field may contain essentially anything. See RFC3986
<
http://tools.ietf.org/html/rfc3986#section-3.2.2>.
/You can put the same information into a list. And you can put
essentially anything in the hierarchical part of a URI. /
This argument points out an obvious truism: that it is certainly
possible to design name mangling rules that convert between
s-expressions and URIs. That misses some points, though:
1. That doesn't help when it comes to externalizing names.
Consider writing a program, not in Scheme, which accepts as input
the name of a Scheme library and performs a database query, using
that name as a key. We would like people to be able to cut and
paste library names from Scheme source code into the input to this
program. That program will have to implement the name mangling
rules. Given the subtleties of Scheme s-exp syntax, that mangling
algorithm is considerably more complicated than, say, a regexp
rewrite rule. S-exps are a good thing but they aren't easily the
Right Thing for data that is expected to be externalized.
2. Name mangling will produce ugly results.
Scheme symbols use a different set of characters than URI path
components and Scheme numbers use a different syntax for numbers
than is commonly used in modern protocol standards. It is
difficult to imagine a name mangling algorithm that won't produce
ugly, hard-to-read results for some s-exp based library names.
3. S-exps, as used in the draft, are a lousy model for URIs.
The particular s-exp library names in the draft are a poor model for
URIs. For example, they offer no way to specify distinguished
schema and authority for a name.
4. The motivation for s-exp library names is suspect.
The main "pro" argument for s-exp based library names seems to be a
desire to standardize the rule for mapping a name used to refer to a
library to the installed library presumed to be intended. Thus, in
the draft, implementations are expected to "peek into" the internal
structure of library names and do things like version number
comparisons according to the editor's particular whim of what those
comparisons entail. What is missing from that "pro" argument is
any rationale that would persuade us such a feature ought to be
standardized. The list of languages which do not specify built-in
version numbers as part of how library names are resolved is quite
impressive -- the draft proposes that Scheme should be quite
exceptional in this regard.
-t
Mikael Tillenius wrote:
> Thomas Lord escribi?:
>> Mikael Tillenius wrote:
>>> Do you realize that you are talking about two different things att
>>> the same time: how a name is _choosen_ and how a name is _represented_.
>>
>>
>> Why do you think that those are separate questions?
>>
>> For example, a URI's representation includes the scheme,
>> authority fields, and a hierarchical part. That
>> representation very much shapes how names are chosen.
>
> You can put the same information into a list. And you can put
> essentially anything in the hierarchical part of a URI.
>
> (Btw doesn't the authority field contain a hostname which either
> should be ignored or make us dependent on a central registry?)
>
> /Mikael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.r6rs.org/pipermail/r6rs-discuss/attachments/20070628/55cfb549/attachment.htm
Received on Thu Jun 28 2007 - 16:37:30 UTC