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)
|
On Fri, 2009-09-25 at 16:18 -1000, Shiro Kawai wrote: > 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. 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 ----------------------------------------------------------------