On Fri, 2009-09-25 at 12:09 -1000, Shiro Kawai wrote:
> 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?

I think we should plan to reach there.  (Otherwise, I wouldn't have
ditched the search-by-decoding instead of search-for-encoded algorithm I
had, which simplified the exchanging-files issues with encoded path
components, because it does not scale well to large numbers of files and
many-symbol library names.)

> 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.

But that's still another reason to have the ability to avoid littering
files outside their collection's directory.

> 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).

An Emacs library name is only a symbol, whereas an R6RS library name is
a sequence of symbols.  In order to support subdirectory organization,
Emacs has to add subdirectories to the search paths.  I don't want to do
that because it requires managing the adding/removing of the
subdirectories to/from the search paths for every Scheme implementation
for every collection, and it cannot be automatically assumed that
subdirectories in the search paths should also be search paths because
that would be too confusing with using subdirectories for the compound
library names.

> > 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?

The purpose of `make' is automation, so yeah, what I meant was
"everything not just-untar-in-search-path".

> 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.

Yes, another point in favor of the implicit file name.  But I'm not sure
what you mean by "(acme foo) library always create acme/foo/".  Do you
mean only for this case of a single-library package, or do you mean all
libraries' files should be required to be under their library name's
last symbol?

> I still think the name ^main^ stands out too much, though.

Standing out a lot is the purpose!  What's bad about that?  I want to be
able to quickly visually recognize implicit file paths because their
mapping to library names is different.  I think the ^main^ will grow on
you guys if you just let yourselves get used to it :)  I don't want to
be prejudiced to only Latin characters... :)

> I think it acceptable to reserve a special name for this main file
> and to have a special conflict resolution rule for it

I don't like that because it adds yet another rule, applicable only to
the last path component, to the already non-small number of rules of the
SRFI.

> (e.g. foo/main.sls for main file, and (foo main) maps to foo/main/main.sls)

So this rule is(?): if a library name ends with the symbol main, then it
avoids conflict by adding a last path component with prefix "main"?
That would avoid the infinite number of possibilities for conflict
problem the PLT method has.  But that means you can never put a
(foo main) library in the "foo" directory, which I don't like.

--
: Derick
----------------------------------------------------------------