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