[ 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
On Wed, 28 Feb 2001, Simon Marlow wrote:
GHC's package mechanism will actually work pretty much unchanged with this scheme, I believe.
I hope that module name clashes across packages will not be fatal. That's why it should probably be somewhat unified with the package system, not built on top of it. I would prefer to be able to just write a full module path in the import clause, including the package name, instead of being forced to put appropriate -package options in the makefile. -- Marcin 'Qrczak' Kowalczyk
Simon Marlow wrote:
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).
Yes, that's what I had in mind. My guiding design principle is that I want absolutely minimal changes to the current way of doing things, while still managing to gain new expressiveness in the module namespace.
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.
Exactly. When the dot-extended module name is explicitly given, in full, in the source file's "module" header, then it doesn't matter where the compiler is invoked from. cd .; ghc -c A/B/C/D.hs cd A; ghc -c B/C/D.hs cd A/B; ghc -c C/D.hs CD A/B/C; ghc -c D.hs are all equivalent. No special flags are required to tell the compiler that the "root" of this tree is at the parent of A. The source file contains everything the compiler needs to know.
* 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.
I can confirm that Simon's interpretation was exactly what I intended, once again.
GHC's package mechanism will actually work pretty much unchanged with this scheme, I believe.
Good. I don't know much about the package mechanism. Is there a specification document available on the web? Regards, Malcolm
Malcolm Wallace wrote:
Simon Marlow wrote:
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).
Yes, that's what I had in mind. My guiding design principle is that I want absolutely minimal changes to the current way of doing things, while still managing to gain new expressiveness in the module namespace.
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.
Exactly. When the dot-extended module name is explicitly given, in full, in the source file's "module" header, then it doesn't matter where the compiler is invoked from.
cd .; ghc -c A/B/C/D.hs cd A; ghc -c B/C/D.hs cd A/B; ghc -c C/D.hs CD A/B/C; ghc -c D.hs
are all equivalent. No special flags are required to tell the compiler that the "root" of this tree is at the parent of A. The source file contains everything the compiler needs to know.
Yes, it is easy to find a module file given the filename, but how does the compiler find modules that this module imports? -- Christian Brolin
Fri, 09 Mar 2001 08:23:49 +0100, Christian Brolin
Yes, it is easy to find a module file given the filename, but how does the compiler find modules that this module imports?
It is given a set o import directory roots (-i option on ghc + roots resulting from -package options, -I option on nhc98). -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK
participants (5)
-
Christian Brolin -
Malcolm Wallace -
Marcin 'Qrczak' Kowalczyk -
qrczak＠knm.org.pl -
Simon Marlow