Re: Proposal: module namespaces.
Malcolm Wallace wrote:
Christian writes:
What about the module declaration? Should it be: module Text.Xml.Parser where ... or just module Parser where ... -- located in Text/Xml/Parser.hs?
The former. The reason is that a compiler needs to generate a unique linker symbol for each defined function. If the full module name is not encoded in the source file, you will need to add a commandline option to the compiler, which is the wrong way to go in my opinion.
What?? The compiler knows the full name of the module without the module clause. If it didn't do that, it can't find the modules to compile! Does the compiler opens every file on the Internet to check whether it is the file to compile? How does the compiler find the file to compile in the first place? What should the command line option you mentioned do?
Why is e.g. Parser.f not sufficient as a unique symbol for Text.Xml.Parser.f? Well, what if you also have Text.Html.Parser.f? You really need the full thing.
Of course, see above.
I would also like to import modules using relative addresses, e.g. the file: My/Small/Test/Xml/Parser.hs contains: import .Lexer -- Relative path to the module: My.Small.Test.Xml.Lexer import ..Data -- Relative path to the module: My.Small.Test.Xml.Parser.Data import Text.ParserCombinators.HuttonMeijer -- Absolute address
I'm sorry, I don't entirely follow what the differing numbers of initial dots mean.
They are used to specify relative addresses to other modules. Relative addresses is a very important concept, but You missed it in your proposal. The dots was just my suggestion of a syntax for relative addresses. One dot: Relative to the parent of this module. Two dots: Relative to this module. E.g. module A.B.C.D1 where import A.B.C.D1.E1 import A.B.C.D1.E1.F import A.B.C.D1.E2 import A.B.C.D2 import X.Y.Z would be the same as (delete 'A.B.C'): module A.B.C.D1 where import .D1.E1 import .D1.E1.F import .D1.E2 import .D2 import X.Y.Z would be the same as (delete 'D1'): module A.B.C.D1 where import ..E1 import ..E1.F import ..E2 import .D2 import X.Y.Z Move the package of modules (A.B.C.*) to (Std.AAA.BBB.CCC.*) and rename D1 to DDD: module Std.AAA.BBB.CCC.DDD where import ..E1 import ..E1.F import ..E2 import .D2 import X.Y.Z The only thing that needs to be changed is the module clause. Which of course would be unnecessary if the module clause was dropped.
When the world realize that this is the XML parser, they won't accept the name and I refuse to change my implementation. The only thing that is needed to rename (an unused) module hierarchy is to move it.
If you refuse to change your implementation, someone else will change it for you! You can't have closed standards.
It is not necessary to modify the modules if the module system supports relative addresses!!! The steering wheel of my car is positioned relative to my car, so it is NOT necessary to change that position when I move the car. -- Christian Brolin
On Wed, 28 Feb 2001, Christian Brolin wrote:
What?? The compiler knows the full name of the module without the module clause.
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. I'm not saying that I want to have to write full paths, but I see no other choice.
The dots was just my suggestion of a syntax for relative addresses. One dot: Relative to the parent of this module. Two dots: Relative to this module.
It's confusing. If at all, it should be the opposite, analogous to . and .. directories. But it doesn't look clear either. -- Marcin 'Qrczak' Kowalczyk
Marcin 'Qrczak' Kowalczyk wrote:
On Wed, 28 Feb 2001, Christian Brolin wrote:
What?? The compiler knows the full name of the module without the module clause.
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.
I'm not saying that I want to have to write full paths, but I see no other choice.
The dots was just my suggestion of a syntax for relative addresses. One dot: Relative to the parent of this module. Two dots: Relative to this module.
It's confusing. If at all, it should be the opposite, analogous to . and .. directories. But it doesn't look clear either.
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 -- Christian Brolin
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
Marcin 'Qrczak' Kowalczyk wrote:
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.
This dilemma comes from the fact that you don't tell the compiler what module to compile, but just give it some Haskell code. You should always compile the module with: compile A.B.C.D, i.e. tell the compiler which module you want to compile, and the compiler will find the source code.
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.
Or A.B.C.D.E, so the first is not needed either. The idea is to avoid redundant information, not to save some typing. I can go with: import parent.D2 import parent.this.E where 'parent' and 'this' are two new reserwed words. I want relative addresses to be able to easily move packages of modules.
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.
What? The concept of relative addresses or just my home made dot-syntax?
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).
I think this is very confusing! And restrictive.
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.
Yes, in the case of a file system, you have to specify a set of directories for the compiler to search for the sources. The compiler should look for the module A.B.C.D and not the module D. I would like to compile the program above with: hcc -i~brolin/haskell/test A.B.C.D The compiler understands the import clauses and locates the imported modules and recursively compiles the ones that need to be compiled. The above command is not the same as: hcc -i~brolin/haskell/test/A/B/C D Since this compiles the module D and not the module A.B.C.D. (The last dot is a period and is not part of the module identification:) The module A.B.C.D can be mapped to the file system, e.g. Unix: ~brolin/haskell/test/A/B/C/D.hs or maybe: ~brolin/haskell/test/A.B.C.D.hs or maybe a compiled package: ~brolin/haskell/packages/ABCD.har -- Christian Brolin
Wed, 28 Feb 2001 17:31:13 +0100, Christian Brolin <Christian.Brolin@carmen.se> pisze:
This dilemma comes from the fact that you don't tell the compiler what module to compile, but just give it some Haskell code. You should always compile the module with: compile A.B.C.D, i.e. tell the compiler which module you want to compile, and the compiler will find the source code.
It must work well with Makefiles. I can imagine that it's doable in this case, but generally it should work to specify the filename too.
I would drop it.
What? The concept of relative addresses or just my home made dot-syntax?
The dot-syntax, and faced with inability of finding a better scheme - the concept.
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).
I think this is very confusing! And restrictive.
It may be confusing (but not more than having your own function called sortBy). It's not restrictive. When you want to use a module, don't provide a module of the same name - *that* would be confusing when used (if allowed). It has an advantage that it's simpler. The compiler has a set of roots and there is just one form of module paths. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK
Wrong namespace! Could you please, move your further discussion on this subject to libraries@haskell.org? You pauperize the other archive while polluting this one. Jan
participants (4)
-
Christian Brolin -
Jan Skibinski -
Marcin 'Qrczak' Kowalczyk -
qrczak＠knm.org.pl