>From: Derick Eddington <xxxxxx@gmail.com>
Subject: Re: Please drop the ^main^ thing
Date: Fri, 25 Sep 2009 14:02:40 -0700

> > Just as a data point, I don't have desire to organize a library
> > under a single directory.   I don't mind the library tarball
> > expands into acme/foo.sls, acme/foo/helper1.sls, acme/foo/helper2.sls...
>
> How do you feel about "littering" the top of a search path directory
> with acme.sls, etc., for single-symbol-named libraries?  (I'm asking
> just to know your opinion.)  (I think there will be enough
> single-symbol-named libraries that it will happen without support for an
> implicit file name.)

I don't mind unless there are several thousand files in
a same directory.   Do you think we'll reach there?  If we put
per-implementation precompiled files (e.g. fasl or dso) in
the same location of *.sls, maybe.  But such
implementation-specific files doesn't need to follow srfi-103,
and probably should be encouraged to put files under subdirectory.

I just looked into /usr/share/emacs/*/lisp.  Mine had less than
300 (but I only installed *.elc).   Heavy emacs customizers
may have a lot more.  It still seems manageable.   Interestingly,
xemacs uses one-directory-per-package policy.  But if I remember
correctly it adds every such directory to the search path (I no
longer use xemacs so I'm not sure).

> While I do like automated management for library collections, and I look
> forward to having more automated management, I also think it's important
> to support collections which can simply be manually dropped into a
> search path and be immediately ready and which can be effectively
> manually managed, and that it's important to not marginalize this by
> saying everyone should use automated management.  (I know you weren't
> saying that and were just giving your personal opinion, which I
> appreciate.)

I'm not sure how much you mean by "automated management".
Is untar + make install considered that automated?

However, if many people like "just-untar-in-search-path",
then I support everything-under-subdirectory in a different
reason.  Many libraries need accompanied files such as
README and COPYING.   If we eventually agree a common
format of meta information (e.g. XEmacs' _pkg.el), such
file may also needed.   If the library consists of a single
source file, acme/foo.sls, then it's ambiguous how the
library author include those auxiliary files.  So it'll
be reasonable that (acme foo) library always create
acme/foo/ subdirectory and put everything under that.

I still think the name ^main^ stands out too much, though.
I think it acceptable to reserve a special name for this main file
and to have a special conflict resolution rule for it
(e.g. foo/main.sls for main file, and (foo main) maps to foo/main/main.sls)
After all, R6RS library syntax itself has an extra rule
for libraries whose first component is one of a specific set of
words.   We don't need to pretend "no reserved words" in this srfi.

--shiro