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