>From: Derick Eddington <xxxxxx@gmail.com>
Subject: Re: Please drop the ^main^ thing
Date: Fri, 25 Sep 2009 17:59:03 -0700

> > 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 meant the latter.  If the library is untarred somewhere else
and 'make install'ed, auxiliary files can be left in the
untarred site (or 'make install' puts them in different
place).  But if we just want to untar directly under library
path, then I'd prefer a library package expands into a single
directory, under their library name's last symbol.  E.g.
if a package provides (acme foo) (acme foo helper1) (acme foo helper2),
everything is under acme/foo/, including README.

> > I still think the name ^main^ stands out too much, though.
>
> Standing out a lot is the purpose!  What's bad about that?

I guess nothing is bad except weird feeling.  On the other
hand, I don't need to name my C program entry point to
int ^main^(int, char**) or int MAIN(int char**) or something
that stands out.  I trained to spot "main" specially.

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

On the other hand, using a plain 'main' name removes one rule
"^ must be encoded".  I got an impression that inclusion of '^'
in the to-be-encoded character is ad-hoc, only to support the
name ^main^.

> > (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"?

Yes.  It is similar to this rule in r6rs library syntax:
"A <library reference> whose first <identifier> is for, library,
only, except, prefix, or rename is permitted only within a
library <import set>."

I personally think this kind of rule ad-hoc, but in practice
a couple of such rules won't hurt and people get used to it.

> But that means you can never put a
> (foo main) library in the "foo" directory, which I don't like.

This part I didn't get.  Can you explain in examples?

--shiro