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.