Hi Georg, Georg wrote:
> 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. Yes, tools need to, somehow, locate modules. Yes, for portability reasons, it is convenient if tools support common conventions. But that does not mean that the *language standard* should nail down these details. > 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 No, you don't. What is, in principle, wrong with a Haskell implementation that scans whatever files it is given as input, determines the modules in them, and compile those? That would even allow multiple modules in one file, and possibly facilitate compilation of mutually recursive modules. I wrote such a compiler once. One can argue about wheteher that's a good approach or not, but why shouldn't that be an acceptable implementation? When it comes to precompiled library hierarchies, they are specific to particular compilers. Why should the language standard say anything about how that compiler should organize its libraries? Leave that decision to the implementors. > 2) All file systems I know provide hierarchical structures Yes. But future file systems may go beyond that, towards a more database-like organization, say. While I don't seriously suggest that would imply that there wouldn't be support for hierarchical names as well, why should tools not be able to exploit such new facilities? > 3) All files in one place seems not to be a feasible solution for > larger project and reusability, I think. No, that wasn't what said. I simply said that whoever is in charge of a project, is the one pest placed to decide how the source files should be organized. And if they happen to want to put the files into a database, and have some Haskell implementation that supports that, then all the power to them. > 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! For all conceivable systems one possibly might want to run a Haskell system on? E.g. Hugs has a very small foot-print and could be made to run, say, in a pretty-small embedded system on top of how-knows what kind of arcane real-time OS? And what other restrictions on lengths etc. are there out there? Anyway that is beside the point. The point is that to have a solid language definition, one would have to decide on a specific set of file systems to support, or at least nail down a minimal set of features that a file system must have, thus potentially ruling out certain present or future file systems and/or operating environments. > If you leave everything to the programming environment, it is very > complicated to organise a project for multiple > environments/compilers. I think e.g. Cabal and related efforts are a testimonial to the opposite. All the best, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham [EMAIL PROTECTED] 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. _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime