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 03:21 +0300, Abdulaziz Ghuloum wrote: > It seems to me that this ^main^ convention is beneficial only > to libraries whose names is a single component, e.g., (foo). It's not only for single-component library names. If you have libraries (acme foo), (acme foo helper1), and (acme foo helper2), you may want them all organized under "acme/foo". > Libraries distributed in a collection do have a common prefix > and don't usually need an implicit ^main^ file. (right?) A collection of libraries with common prefix (acme ---) might have an (acme) library and you may want all the libraries organized under "acme". I don't know how usual this will be. I've been under the impression there's enough demand for the organize-under-the-same-directory ability of the implicit file name to justify supporting it. I could be wrong. Am I? > I also noticed that the two carets are very disturbing and this > might have severe long-term effect on your visual apparatus > (maybe more than Scheme's excessive use of hash marks). The intent of the carets is to visually stand out. That way you see "^main^.sls" and know it's an implicit file for the library with name corresponding to the path up to the file. Using a "protector" character (currently #\^) which is encoded is done to avoid adding an additional rule, applicable to only the last path component, for avoiding conflicts with library names whose last symbol is the same as the implicit file name. PLT's implicit file name is "main.sls", and it avoids conflicts by prepending #\_. E.g., (foo main) => "foo/_main.sls", (foo _main) => "foo/__main.sls", and so on. I prefer using an encoded protector character to avoid conflicts because it uses the already-existing rule for path encoding, and because only one possibility for conflict exists instead of an infinite number of possibilities. E.g., only (foo ^main^) conflicts instead of an infinite number of (foo main), (foo _main), (foo __main), and so on. I'm open to changing the protector character and where it's positioned and how many times it occurs. Whatever the protector character is, I think it should be encoded in all path components (i.e. where it's technically unnecessary), to avoid causing an exceptional rule for the last path component. > I think the second reason by itself is sufficient to drop the > caret-main-caret convention, but would like to know what others > think. Are the benefits worth the complications? Should they > be dropped or kept? I would also like to know what others think. I've been under the impression enough people want the implicit file name ability, and for not only single-component library names but also for multiple-component ones, and that using an encoded protector to avoid additional rules is good. In the SRFIs collection I maintain, I could take advantage of the implicit file name for all the (srfi :X) alias libraries by putting their files under the "srfi/%3AX" directories where the (srfi :X Y) libraries are. I think this would be better organization. Being able to organize all libraries with a shared name prefix under the same directory seems desirable so that, when managing the related libraries, the directory is the single thing for them, instead of having to remember there's also the file outside the directory and also deal with it. E.g., a collection with (acme) library is distributed in a tar/zip with files all under the "acme" directory, and when you want to move/delete it you only need to remember and deal with the directory. However, the implicit file name does cause variability in where a library's file might be located. In SRFI 103, I say: Single-library files have advantages over multiple-library files: (1) the process for finding libraries is not as complex; (2) when people want to find the files containing specific libraries, they do not have to hunt them down by identifying the many possibilities and checking each; If we got rid of the implicit file name, the number of possibilities where a library's file can be located would be reduced from (* 2 number-of-search-paths) to number-of-search-paths. It would still be possible to distribute collections with a library named the same as the collection, e.g. (acme), as a single tar/zip, because the library's file can be in the tar/zip outside the directory (but then we have to remember it is outside and deal with it being outside). -- : Derick ----------------------------------------------------------------