On 12 May 2005 15:49, Isaac Jones wrote:
I don't mind this change much, it might even be good. One thing I like about the old way, though, is that it encourages people to use the hierarchical namespace, which is a nice way to organize things whether you are building a library or an executable.
But Cabal's purpose is to help folks build tools, not to enforce style ;) I'd accept it if you feel that you need it. Anyone else have an opinion?
It's a trivial change to make, it doesn't break anything, and it lets us support more existing projects without substantial reorganisation of their file structure. Sounds like a no-brainer to me. Cheers, Simon
Hi all, Simon Marlow wrote:
It's a trivial change to make, it doesn't break anything, and it lets us support more existing projects without substantial reorganisation of their file structure. Sounds like a no-brainer to me.
I've never liked the close de-facto connection between the hierarchical module name space and and the actual source tree. In fact, at times, in the Yampa build system, I tried very hard to work around that connection (as Simon might recall, something involving allowing "." in file names as an alternative to subdirectories, I believe). The proposal seems like a step in the right direction. Go for it! /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham nhn@cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.
On Thu, May 12, 2005 at 05:34:06PM +0100, Henrik Nilsson wrote:
Hi all,
Simon Marlow wrote:
It's a trivial change to make, it doesn't break anything, and it lets us support more existing projects without substantial reorganisation of their file structure. Sounds like a no-brainer to me.
I've never liked the close de-facto connection between the hierarchical module name space and and the actual source tree. In fact, at times, in the Yampa build system, I tried very hard to work around that connection (as Simon might recall, something involving allowing "." in file names as an alternative to subdirectories, I believe). The proposal seems like a step in the right direction. Go for it!
Jhc has just this extension. it looks for Control.Monad.Writer in all of Control/Monad/Writer.hs Control/Monad.Writer.hs Control.Monad.Writer.hs I would like to see it in other compilers too... John -- John Meacham - ⑆repetae.net⑆john⑈
On Thu, 12 May 2005, John Meacham wrote:
On Thu, May 12, 2005 at 05:34:06PM +0100, Henrik Nilsson wrote:
Hi all,
Simon Marlow wrote:
It's a trivial change to make, it doesn't break anything, and it lets us support more existing projects without substantial reorganisation of their file structure. Sounds like a no-brainer to me.
I've never liked the close de-facto connection between the hierarchical module name space and and the actual source tree.
I don't see the advantage of giving every programmer his own style in this respect, or even allow mixing dotted file names and separation by directories. When I read import Control.Monad.Writer I know that the file Writer.hs is in Control/Monad, very easy. What's so bad about using directories? Bad support by CVS? Then use darcs. Separating module names and file locations adds a new level of complexity but for what benefit?
On Fri, May 13, 2005 at 09:23:18AM +0200, Henning Thielemann wrote:
On Thu, 12 May 2005, John Meacham wrote:
On Thu, May 12, 2005 at 05:34:06PM +0100, Henrik Nilsson wrote:
Hi all,
Simon Marlow wrote:
It's a trivial change to make, it doesn't break anything, and it lets us support more existing projects without substantial reorganisation of their file structure. Sounds like a no-brainer to me.
I've never liked the close de-facto connection between the hierarchical module name space and and the actual source tree.
I don't see the advantage of giving every programmer his own style in this respect, or even allow mixing dotted file names and separation by directories. When I read import Control.Monad.Writer I know that the file Writer.hs is in Control/Monad, very easy. What's so bad about using directories? Bad support by CVS? Then use darcs. Separating module names and file locations adds a new level of complexity but for what benefit?
It is funny you should mention this. I need this feature exactly to get around limitations of darcs that wern't a problem with CVS :). Darcs can't compose multiple repositories such that they share a root, therefore in order to compose several haskell projects, I need to treat each of their source directories as potential locations of haskell code. There are a _lot_ of external factors that constrain the way one may lay out files. Making cabal less flexible in this regard would only make it less likely to be adopted. I already had to jump through hoops to get hierarchical names to play well with automake due to its ideas of what goes in subdirectories were different than haskells and it wasn't very fun and not the sort of thing I like to do. (fight my tools) We should make cabal very flexible if we expect it to be used. John -- John Meacham - ⑆repetae.net⑆john⑈
On Fri, May 13, 2005 at 12:46:26AM -0700, John Meacham wrote:
It is funny you should mention this. I need this feature exactly to get around limitations of darcs that wern't a problem with CVS :). Darcs can't compose multiple repositories such that they share a root, therefore in order to compose several haskell projects, I need to treat each of their source directories as potential locations of haskell code.
There are a _lot_ of external factors that constrain the way one may lay out files. Making cabal less flexible in this regard would only make it less likely to be adopted. I already had to jump through hoops to get hierarchical names to play well with automake due to its ideas of what goes in subdirectories were different than haskells and it wasn't very fun and not the sort of thing I like to do. (fight my tools) We should make cabal very flexible if we expect it to be used.
Hmm.. I think I may have been confused about what feature I was responding too here... but the reasoning is more or less the same for both changes. John -- John Meacham - ⑆repetae.net⑆john⑈
participants (4)
-
Henning Thielemann -
Henrik Nilsson -
John Meacham -
Simon Marlow