[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Please drop the ^main^ thing

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 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(?):


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