I think the namespace proposal wants to be strictly upward compatible, therefore it's perhaps not the right time to discuss this ... but still I think the question "why should the source text of a module contain its name?" wants an answer. Even if we stick to module headers, I don't really like the idea of `module Fully.Qualified.Name where ..' The proposal mentions the analogy to Java. My knowledge of that is minimal, but in Java, they have `package Foo.Bar.Frobs' (full name required) and `class Frobble' (only last name there). So, a Haskell module corresponds to what? I understand the argument "the compiler needs to generate unique names in the object files" but this is a matter of implementation, about which the programmer (at least theoretically) should not care. I think the underlying design decision here is: how far should the user of a set of modules expect that he can move their source/interface/object files around, and still compile them/link against them correctly. The present proposal seems to imply: not at all. This is a conservative answer. It is easy to implement, and guarantees some consistency. Is it too restrictive? But assume this policy is adopted. Then I am not allowed to move (precompiled) modules around physically. That's why I want some means of renaming them (during importing), and as I wrote earlier, not only for single modules (`import Foo as Bar') but also for complete hierarchies (`import Leipzig.Standard as Standard') A potential problem is that the root of some hierarchy perhaps is just a directory (that contains subdirs and modules) but not itself a module. One would need to write a dummy module that just (qualified-)imports and re-exports all submodules. But this had to be extended whenever a submodule is added. This doesn't feel right. (On the other hand, the libFoo.a file had to be rebuilt anyway on such an occasion.) This leads to another question - during the linking stage: when should the compilation manager look for a single object file, and when should it expect an archive? Anyway I think even the most restricitve form of hierarchical module names would be very helpful. I certainly would start using it. -- -- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ -- -- joe@informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/252 --
Johannes Waldmann wrote:
I think the namespace proposal wants to be strictly upward compatible, therefore it's perhaps not the right time to discuss this ... but still I think the question "why should the source text of a module contain its name?" wants an answer.
Perhaps. But it is required in Haskell'98, and I don't intend to move away from the standard too far.
Even if we stick to module headers, I don't really like the idea of `module Fully.Qualified.Name where ..'
Initally I thought this might be very verbose, and perhaps people would be reluctant to use long names. However, after playing with adding full hierarchical names to several hundred modules, I discovered I liked using the longer names. They give extra clarity, and in practice you only have to write them once or twice per module, so very little extra keyboard-pounding is required. I'm also a fan of import-renaming, and would highly recommend that the style import qualified Very.Long.And.Tedious.Module.Name as X be used more frequently, even for shorter names: import Pretty as PP
Then I am not allowed to move (precompiled) modules around physically.
The question of where the interface/object files are stored is really a matter for the compiler. The location in the namespace hierarchy is conceptually independent (although for most systems I suppose it is likely to coincide).
That's why I want some means of renaming them (during importing), and as I wrote earlier, not only for single modules (`import Foo as Bar')
Easily done using the current Haskell'98 mechanism.
but also for complete hierarchies (`import Leipzig.Standard as Standard')
This is not part of my namespace proposal. I don't really see how one can easily distinguish a renaming of a hierarchy from a renaming of a simple module. Perhaps a syntactic method of distinguishing them would be required.
Anyway I think even the most restricitve form of hierarchical module names would be very helpful. I certainly would start using it.
My feeling is to go for the minimal extension to Haskell'98 first. After some experience of using it, people will report what extra facilities they find they would really like. Regards, Malcolm
participants (2)
-
Johannes Waldmann -
Malcolm Wallace