[ leaving out haskell@haskell.org from the recipient list ]
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?
The compiler finds the file because you tell it what the filename is. That's the way it works now, and if I understand correctly Malcolm isn't suggesting we change that (and I agree). There are really two issues here: * how do you find a module to compile in the first place (not an issue for interpreters, only for batch compilers). Just run the compiler giving it the filename. * when you import a module, how does the compiler find the interface (or source, in the case of an interpreter) for the target. My feeling is that this happens with a small extension to the current scheme: at the moment, the compilers all have a list of search paths in which to find interfaces/sources. The change is that to find a module A.B.C you search in D/A/B/ (for each D in the search path) rather than just D. GHC's package mechanism will actually work pretty much unchanged with this scheme, I believe. Cheers, Simon