Email list hosting service & mailing list manager

Please drop the ^main^ thing Abdulaziz Ghuloum (25 Sep 2009 00:21 UTC)
Re: Please drop the ^main^ thing Derick Eddington (25 Sep 2009 18:23 UTC)
Re: Please drop the ^main^ thing Derick Eddington (25 Sep 2009 19:37 UTC)
Re: Please drop the ^main^ thing Derick Eddington (25 Sep 2009 19:42 UTC)
Re: Please drop the ^main^ thing Derick Eddington (25 Sep 2009 19:40 UTC)
Re: Please drop the ^main^ thing Derick Eddington (25 Sep 2009 19:47 UTC)
Re: Please drop the ^main^ thing Abdulaziz Ghuloum (26 Sep 2009 08:37 UTC)
Re: Please drop the ^main^ thing Shiro Kawai (25 Sep 2009 19:59 UTC)
Re: Please drop the ^main^ thing Andreas Rottmann (25 Sep 2009 20:33 UTC)
Re: Please drop the ^main^ thing Derick Eddington (25 Sep 2009 22:04 UTC)
Re: Please drop the ^main^ thing Derick Eddington (26 Sep 2009 01:16 UTC)
Re: Please drop the ^main^ thing Derick Eddington (25 Sep 2009 21:02 UTC)
Re: Please drop the ^main^ thing Shiro Kawai (25 Sep 2009 22:07 UTC)
Re: Please drop the ^main^ thing Derick Eddington (26 Sep 2009 01:07 UTC)
Re: Please drop the ^main^ thing Shiro Kawai (26 Sep 2009 02:16 UTC)
Re: Please drop the ^main^ thing Abdulaziz Ghuloum (26 Sep 2009 06:10 UTC)
Re: Please drop the ^main^ thing Shiro Kawai (26 Sep 2009 07:59 UTC)
Re: Please drop the ^main^ thing Abdulaziz Ghuloum (26 Sep 2009 08:14 UTC)
Re: Please drop the ^main^ thing Derick Eddington (27 Sep 2009 03:26 UTC)
Re: Please drop the ^main^ thing Shiro Kawai (27 Sep 2009 04:59 UTC)
Re: [OT] English Derick Eddington (27 Sep 2009 05:29 UTC)

Re: Please drop the ^main^ thing Shiro Kawai 26 Sep 2009 02:18 UTC

>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