/*6.7 Compound library names*
/
/Libary names are compound. This differs from the treatment of
identifiers in the rest of the language. Using compound compound
names reflects experience across programming languages that a
structured top-level name space is necessary to avoid collisons.
Embedding a hierarchy within a single string or symbol is certainly
possible. However, the editors became convinced by the arguments in
favor of using list data to represent hierarchical structure, rather
than encoding it in a string or symbol. Versioning, in particular,
is natural in list form, but awkward in encoded form. Consequently,
despite the syntactic complexity of compound names, and despite the
potential mishandling of the hierarchy by implementations, the
editors chose the list representation./
This design decision rebels against industry best practices, for no good
reason. It creates more awkwardness than it eliminates.
The design of library names should take into consideration that they
will be used externally and how they are likely to be used
externally. For example, implementations must map library names to
external file names. Web applications (e.g., a server for Scheme
packages) need to map library names into resource identifiers.
For those external uses, library names should:
1. Be single identifiers in a commonly accepted syntax for such.
2. Be comparable, for equality, using a simple canonicalization and
string comparison.
3. Be allocated in a non-rival, distributed manner.
4. Where such names have hierarchical structure or other structure such as
version numbers, that structure should be defined over
commonly accepted domains of values, using commonly accepted
surface syntaxes for those values and the structure.
Those rules will allow Scheme library names to be intelligently handled
by many commodity, generic applications which are built with no
particular knowledge of Scheme. Those rules will make it easier to
define network protocols in which Scheme library names occur as atomic
elements. By way of contrast, if S-exp syntax is used for library
names, external applications must be taught how to canonicalize those
names (e.g., adjusting whitespace), how to parse them from a stream, how
to compare them and so forth.
URIs (see RFC 2396 "Uniform Resource Identifiers (URI): Generic Syntax")
fit the bill perfectly.
<http://www.faqs.org/rfcs/rfc2396.html>
As an example, consider two library names in s-exp syntax which differ,
on the surface, in whitespace and in the use of Unicode escapes in some
identifier names. (One version of the library name is in ASCII, say,
and uses escapes -- the other is just uses the same Unicode characters
directy). These two names are logically equal, but consider what it
will take to use them as keys in a generic database.
In contrast, consider two library names which are URIs. The simple
rules for canonicalizing and comparing URIs are widely implemented
already. It will be easy to use those as database keys.
-t
_______________________________________________
r6rs-discuss mailing list
r6rs-discuss@lists.r6rs.org
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
