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