Hi Henrik, On Tuesday 21 February 2006 16:50, Henrik Nilsson wrote:
Hi all,
Georg Martius wrote:
I have some proposals for changes of the hierarchical module system as it is at the moment. [...] The hierarchical name can be derived from the place in the filesystem.
This is not a comment about the above proposal in itself, which arguably has its merits, but rather a meta comment.
I get very anxious whenever I see "the file system" being mentioned in the context of a *language* specification (as opposed to, say, a specification of standard language libraries for interfacing with file systems).
Well, the hierarchical module system as it is implemented today and how it is proposed for being included into Haskell' uses the file system to locate modules. It could of course be a mapping like I think John Meacham proposed with dots or whatever you like, but the point is that: 1) You need some (preferable hierarchical) storage to reflect the structure of your modules 2) All file systems I know provide hierarchical structures 3) All files in one place seems not to be a feasible solution for larger project and reusability, I think.
Some reasons: * File systems have all kinds of quirks one would rather not deal with in a language spec. * File systems can differ radically between different operating systems. In fact, even within an OS, as OS's these days tend to support many file systems simultaneously. True, but do these differences matter to us? Sorry for my naivety, but I can't see that much problems, expect very old 8.3 restrictions, but they are history now! * A valid module names in a language is not necessarily the same as a valid file name. (Yes, bijective mappings could be defined, but they would only be valid for a specific set of file systems.) We don't need bijection, we only need Haskell->Filesystem, which in all means should not be a problem. * Even if we assume that the notion of a hierachical module name space always can be mapped to a corresponding file hierarchy in a simple way, why should that assumption be made in a language specification?
In my opinion it is the task of the programming environment to locate the source files and interfaces that make up a semantically meaningful unit, and that semantics should be completely independent of where the different pieces happen to be stored. If you leave everything to the programming environment, it is very complicated to organise a project for multiple environments/compilers.
Cheers, Georg
I'm already somewhat unhappy about the way most present Haskell tools map module names to path names (I'd generally prefer to have the possibility to flatten my file hierarchies by, say, using dots in my file names), but at least these assumptions are not in the Haskell 98 language definition.
So, please, to the extent possible, let's keep the file system out of the Haskell' definition!
All the best,
/Henrik