[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Please drop the ^main^ thing

This page is part of the web mail archives of SRFI 103 from before July 7th, 2015. The new archives for SRFI 103 contain all messages, not just those from before July 7th, 2015.

From: Derick Eddington <derick.eddington@xxxxxxxxx>
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.