Wed, 28 Feb 2001 11:44:58 +0100, Christian Brolin <Christian.Brolin@carmen.se> pisze:
It does not. File A/B/C/D.hs can be module A.B.C.D, or module B.C.D which happened to be placed in a directory A, or C.D etc. It's ambiguous.
Only if you give the compiler include pathes to both ~ and ~/A, where ~ is the directory containing your A.
When I am in the directory and compile D.hs, I get different result than when I'm one level up and compile C/D.hs? It's fragile.
I just want to left out the redundant information, and . and .. are what remain. import .D2 -- import [A.B.C].D2 import ..E -- import [A.B.C].[D].E
Skipping D alone is not a big deal, and it's known because it's the current module, so the second form is not needed - you could say .D.E as well. It's still confusing: in path names, you write the initial '/' for an absolute name and omit it for a relative name, but here it's the opposite. I would drop it. Instead I would let the current directory play as an implicit module root. I.e. you can refer to D2 as D2, and in this case you cannot refer to the global module D2 if it exists (but you can refer to D2.Other if D2 is a global directory and there is no local directory named D2). A prefix to add to names of compiled modules will have to be specifiable at the compiler commandline, otherwise projects would be forced to put all their files in deep subdirectories only to generate right module paths. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK