On Sun, Nov 12, 2006 at 11:10:25PM -0500, MichaelL_at_frogware.com wrote:
> ---
> This message is a formal comment which was submitted to formal-comment_at_r6rs.org, following the requirements described at: http://www.r6rs.org/process.html
> ---
> Name: Michael Lenaghan
> Email: michaell at frogware.com
> Type: Simplification
> Priority: Major
> Component: Libraries
> Version: 5.91
> Section: 6.1 Library form (pg 21)
> Dependencies: 6.4 Examples (pg 25)
>
> Summary:
>
> Eliminate compound library names.
>
> Description:
>
> R6RS allows compound library names. Compound names create a variety of
> problems that aren't worth the cost.
>
> * Compound names are harder to read.
>
> Here's part of the example in section 6.4:
>
> (library (my-helpers values-stuff)
> (export mvlet)
> (import r6rs (for (my-helpers id-stuff) expand))
> ...)
>
> It would be difficult to argue that the compound name enhances
> readability. But this is a simple example; import sets can be nested,
> creating far more complex expressions:
>
> (library (my-helpers values-stuff)
> (export mvlet)
> (import r6rs (for (add-prefix (only (my-helpers id-stuff)
> find-dup) mh-id:) expand))
> ...)
>
> Typically the import set identifiers are the first symbol in a list.
> Compound names become an exception to that rule requiring a much more
> careful read of the code to distinguish names from syntax. The ambiguity
> is real; it is possible for a compound name to look exactly like an import
> set. The specification states that in such cases the ambiguity should be
> resolved in favor of library syntax--but in the absence of compound names
> such ambiguity would be impossible; library names would always be
> identifiers and import sets would always be lists. [Library version
> numbers make that statement not quite true, but I'll tackle version
> numbers in a separate comment.]
>
> * Compound names invite a misleading sense of file hierarchies.
>
> Compound names might make more sense if they were related to file
> hierarchies, but they aren't. Indeed, R6RS makes some effort to break the
> link between file names and compound library names. For example, the R6RS
> compound library names (ie, the standard libraries) appear to form a
> logical rather than physical hierarchy; it's unlikely that any
> implementation would make any effort to mirror that hierarchy in files.
> Still, when you see a compound name it's just too easy to assume the
> correspondence.
>
> I don't mean to imply that this is fatal. Rather, I'm suggesting that the
> confusion is natural and I'm asking what benefit is gained by it.
>
> Of course, even worse is the prospect that some implementations might
> actually decide to map compound names to files. That raises the spectre of
> portability issues since the mapping isn't specified and would potentially
> differ from one implementation to the next.
>
> * Compound names invite a misleading sense of hierarchy.
>
> Not only are compound names not file hierarchies, they aren't really
> hierarchies of any kind.
>
> For example, R6RS defines a set of library names. All but one of the names
> is compound. (Technically, of course, all names are compound, but you know
> what I mean.) The one non-compound name, r6rs, appears to be the root of a
> hiearchy, but in fact it's simply another identifier that happens to start
> with the same symbol. Section 21 says:
>
> "The (r6rs) library is a composite of most of the libraries
> described in this report. The only exceptions are..."
>
> So r6rs simply imports a set of libraries and exports their identifiers.
> There is no other relationship between them.
>
> Again, this is not fatal, just a little confusing than it needs to be. And
> again the question is what benefit is gained by the feature to warrant the
> confusion.
>
> * Compound names run counter to the concept of a Scheme identifier.
>
> Scheme has a pervasive concept of identifier. Compound names run counter
> to that concept. That complicates various plausible library enhancements.
>
> For example, Chez's module names are identifiers. In Chez modules can be
> imported and exported via their names. I've built sophisticated object
> systems in Chez that use modules to implement classes. The class
> definition expands into a module definition; the module exports the
> user-accessible part of the class implementation. The generated module is
> automatically imported into local scope. More importantly, though, the
> module that contains the class implementation has a generated name. That
> means that the module containing the class can be exported from *its*
> enclosing module with a single identifier (ie, via the generated module
> name). It also means that the entire class (constructor, class methods,
> instance methods, etc.) can be imported into another module via that
> module name:
>
> (module some-module (some-class)
>
> (module some-class
> (make-some-class
> some-class-a
> some-class-a!
> ...)
> <some private stuff we don't
> want to make visible...>
> ...)
> (import some-class)
>
> ...)
>
> (module some-other-module ()
> (import some-class)
>
> (some-class-a (make-some-class)))
>
> How much will compound names complicate such usage? For example,
> identifiers can be prefixed or renamed during import. Obviously you can
> neither prefix nor rename a compound name using the existing syntax. It
> goes on; in the face of compound names, for example, how do syntax-case'
> free-identifer=? and bound-identifier=? work?
>
> Andre van Tonder added these points on the discussion list; I believe they
> make the same point from a different (and more accurate) perspective:
>
> - The current specification does not generalize to local libraries, which
> are a
> very natural future extension that already exists in at least one major
> Scheme implementation.
>
> Local library names must be identifiers so that they can scope
> lexically and
> be subject to hygiene, like other bindings. The current draft says
> that
> toplevel library names are not identifiers. As a result, an extension
> of the
> current draft that adds local libraries would be forced into the absurd
> situation where toplevel and local libraries belong to two different
> namespaces. It is as absurd as introducing different namespaces for
> local
> and toplevel "define".
>
> - Even if one never needs to add local libraries, the current
> specification
> introduces two namespaces at the toplevel - that is in Schemes that do
> have a
> toplevel, which r6rs does not forbid. This goes against the
> one-namespace
> tradition in Scheme.
>
> (That isn't meant to imply that he agrees or disagrees with anything else
> I've said.)
>
> Recommendations:
>
> * Eliminate compound library names.
>
> This will of course require that all but one of the R6RS libraries be
> renamed.
>
> * Suggest a naming convention for compound library names that are still
> single identifiers.
>
> Someone on the discussion list pointed out that in an identifier like
> r6rs-hash-table it's impossible to see where the breaks are meant to go.
> They suggested that R6RS could produce a convention for naming the parts
> of a compound name within a single identifier--eg, r6rs:hash-table or
> r6rs::hash-table.
+1
Either abolish compound names, or force them to be used for and only
for a library hierarchy.
Indeed, when I read the spec I had the (addled) impression that
compound names *were* used for hierarchy, similar to how in Haskell
import Text.ParserCombinators.Parsec
translates to the file Text/ParserCombinators/Parsec.hs. What else
are they useful for?
--
Trent Buck, Student Errant
Received on Mon Nov 13 2006 - 12:28:05 UTC