Hi, Yitzchak Gale wrote:

But for large and complex projects, this policy really complicates the task of the project manager who wants to be able to present various views of the source to teams working on different subprojects, while juggling the version control in an intelligent way. Directory tree structure is sometimes the perfect tool for that, but Haskell has stolen it away. It would be nice if compilers would offer, as an optional alternative, a system of locating modules based on manifest files. That would then allow multiple modules per source file.

Not that it is of any practical relevance now, but this was exactly the thinking behind the design (some 10 - 15 years ago, time flies!) of how Freja manages files and modules, as Malcolm mentioned. I believe a clear separation between a language and aspects of the environment in which programs are developed, such as file systems, is a good thing. And while the Haskell standard as such respects this, I've always found the fact that most tools rely on naming conventions for mapping names of modules to names of files very unfortunate. Hierarchical modules makes this even worse: what says that I necessarily want the module hierarchy reflected in the directory hierarchy? And indeed, as Yitzchak said, what about non-hierarchical file systems, or maybe storing source code by completely different means? And there are also potential issues with not every legal module name being a legal file name across all possible file systems. So, yes, a system of locating modules based on manifest files would be great. I'd use it all the time whenever possible, and never look back! Best, /Henrik -- Henrik Nilsson School of Computer Science 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 2008-08-27, Henrik Nilsson wrote:

And there are also potential issues with not every legal module name being a legal file name across all possible file systems.

I find this unconvincing. Broken file systems need to be fixed. -- Aaron Denney -><-

On 2008-08-30, Brandon S. Allbery KF8NH wrote:

On 2008 Aug 30, at 4:22, Aaron Denney wrote:

...

On 2008-08-27, Henrik Nilsson wrote:

...

And there are also potential issues with not every legal module name being a legal file name across all possible file systems.

I find this unconvincing. Broken file systems need to be fixed.

Language people trying to impose constraints on filesystems is the tail wagging the dog.

I'd say it's just the opposite. The purpose of a filesystem is to hold user data, in ways convenient to the user, which means dictating a usable interface. Dictating the implementation would be closer to tail wagging the dog, though even that's not quite the right metaphor -- it's just a layering violation. The user is in this case GHC or other compiler adopting the suggestion in the Hierarchical modules extension. Just as non-hierarchical file systems have long been considered broken, I think it's safe to now declare that one that doesn't support unicode in some fashion, even if only a userland convention of using UTF-8, is indeed less usable, and hence broken. -- Aaron Denney -><-

On 2008-08-27, Yitzchak Gale wrote: [hierarchical modules mapped to filesystem paths]

In my opinion, that is a bad policy. It is fine as a simple default for small projects, even though it's a bit ugly and ad hoc. (For example - what does this mean on platforms whose filesystem is not hierarchical?)

The language standards are always going to require something from the platforms we develop on (which is different N.B. than the ones we deploy to). I have no trouble counting real filesystems among them.

But for large and complex projects, this policy really complicates the task of the project manager who wants to be able to present various views of the source to teams working on different subprojects, while juggling the version control in an intelligent way. Directory tree structure is sometimes the perfect tool for that, but Haskell has stolen it away.

This is a valid point, but I personally get extremely frustrated at remapping in source code repositories, precisely because allowing different views means people can say "builds for me" without any guarantee of anything useful for anyone else.

It would be nice if compilers would offer, as an optional alternative, a system of locating modules based on manifest files. That would then allow multiple modules per source file.

And simplify supporting recursive modules... -- Aaron Denney -><-