Re: Please drop the ^main^ thing

[Derick Eddington <derick.eddington@xxxxxxxxx>]

On Fri, 2009-09-25 at 16:18 -1000, Shiro Kawai wrote:
> From: Derick Eddington <derick.eddington@xxxxxxxxx>
> 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.

So the files for those libraries must be(?):

acme/foo/^main^.sls
acme/foo/helper1/^main^.sls
acme/foo/helper2/^main^.sls

because "libraries' files are 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 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.

Another reason I don't like using "main" for the implicit file name is
that I think libraries named (--- main) are not so uncommon that they
should have to be named "---/_main.sls" or "---/main/main.sls"

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

Yes, that is the only reason #\^ is encoded.  The SRFI already has to
specify the encoding of characters, so just adding #\^ to the existing
encoded set in order to accomplish avoiding conflicts with the implicit
file name seemed better than specifying a whole new rule applicable to
only last components named _*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?

Say you have libraries (foo bar) and (foo main) and you want their files
to both be in (not just under) the "foo" directory -- you can't do that
because, by the rule you mentioned, (foo main) must go in
"foo/main/main.sls".  I want to support the ability to use or not use
the implicit file name.

-- 
: Derick
----------------------------------------------------------------