Hello, I have some proposals for changes of the hierarchical module system as it is at the moment. Goals: - easy refactoring at Module/Package level - easier import/export of trees of modules (useful for any larger library) - relative imports/exports - deep import or export lists Notation: I use "X --> Y" to mean X is an example how it is now and Y is my proposed version. 1) Instead of writing the full name of the module in the head line it should be allowed to just use its last part e.g. module System.Posix --> module Posix The hierarchical name can be derived from the place in the filesystem. Pros: - allow much easier refactoring at package level. - reduce redundancy between file location and file content Cons: - loose location information in file itself 2) relative imports/exports: imports/exports of submodules can be specified as a relative path: module System.Posix ( module System.Posix.Env ) where import System.Posix.Env --> module Posix ( module .Env ) where import .Env or whatever syntax you prefere. Pros: - Again, easier refactoring at package level Cons: - the "." might be overseen (I expect long syntax discussions :-) ) 3) Import subtrees: import (qualified) System.Posix.* as P would to the same as import (qualified) System.Posix.Directory as P.Directory import (qualified) System.Posix.Env as P.Env import (qualified) System.Posix.DynamicLinker as P.DynamicLinker import (qualified) System.Posix.DynamicLinker.Module as P.DynamicLinker.Module .... Pros: - Much less imports - easy use of large libraries like Graphics.UI.Gtk Cons: - More modules are imported than necessary 4) Export subtrees: This proposal seems to do the same thing as 3) but on the side of the library not on the calling side. ----------------- module System ( module P.* ) where import qualified Posix.* as P ------------------ module Test where import System -- Posix.Env is in scope now The details about the qualification must be sorted out carefully, but I see no serious problem there at the moment. Pros: - Easy writing of meta-modules - avoids name clashing within submodules (e.g. Data.Map, Data.Set,... which have all insert, lookup,...) Cons: - importing side does not see, that there is a whole tree imported. Comments? Cheers, Georg
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). 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. * 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.) * 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. 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 -- 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.
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
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 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.
PS:
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!
Here's a concrete example, then. Windows file systems don't distinguish case. Thus the two different Haskell modules "FOO" and "Foo" would be mapped to the same file, as far as I can tell? Best, /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 Tue, Feb 21, 2006 at 03:50:29PM +0000, Henrik Nilsson wrote:
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.
me too. which is why I made jhc search for System.IO.Unsafe in System/IO/Unsafe.hs System/IO.Unsafe.hs System.IO.Unsafe.hs in that order. It would be nice if other implementations did this too, but it is not the sort of thing that belongs in a language spec.
So, please, to the extent possible, let's keep the file system out of the Haskell' definition!
I very much agree. John -- John Meacham - ⑆repetae.net⑆john⑈
On Tue, Feb 21, 2006 at 03:50:29PM +0000, Henrik Nilsson wrote:
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.
I'd like to second this. I've been annoyed by the fact that ghc requires extra subdirectories in order to use hierarchical modules, and would be doubly annoyed if the language definition declared that this couldn't be fixed. jhc's behavior sounds nicer, but I'd rather there were the possibility of naming our haskell files whatever we liked. Currently, as far as I can see, we can only do this with Main, and even then there are weirdnesses in ghc because Main.hi gets generated. -- David Roundy http://www.darcs.net
Hello David, Wednesday, February 22, 2006, 4:09:07 PM, you wrote: DR> I'd like to second this. I've been annoyed by the fact that ghc requires DR> extra subdirectories in order to use hierarchical modules, and would be i'll be third :) i planned to fill a ticket but still not done it DR> doubly annoyed if the language definition declared that this couldn't be DR> fixed. jhc's behavior sounds nicer, but I'd rather there were the DR> possibility of naming our haskell files whatever we liked. Currently, as DR> far as I can see, we can only do this with Main, and even then there are DR> weirdnesses in ghc because Main.hi gets generated. and Main.o also. i think that it is not right -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
David Roundy wrote:
DR> fixed. jhc's behavior sounds nicer, but I'd rather there were the DR> possibility of naming our haskell files whatever we liked. Currently, as DR> far as I can see, we can only do this with Main, and even then there are DR> weirdnesses in ghc because Main.hi gets generated.
I don't think this is weird. Java does the same thing: you can have "class Foo {}" in a file named Bar.java, you can compile the file, and you get Foo.class. -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------
David Roundby wrote:
I'd like to second this. I've been annoyed by the fact that ghc requires extra subdirectories in order to use hierarchical modules, and would be doubly annoyed if the language definition declared that this couldn't be fixed. jhc's behavior sounds nicer, but I'd rather there were the possibility of naming our haskell files whatever we liked.
And I'd like to second that! But not a Haskell' issue (I hope). Best, /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.
participants (6)
-
bulat.ziganshin＠gmail.com -
David Roundy -
Georg Martius -
Henrik Nilsson -
Johannes Waldmann -
John Meacham