Ah, so the problem was that even though I had the superdir of NLP in my path, I was actually loading the modules in ghci from the NLP directory. Still, I find this behavior odd, since even if I were in the NLP directory I could not import "NLP.Foo" simply as "Foo", I don't see why I should be allowed to (try to) import "NLP.Prelude" simply as "Prelude", thus messing stuff up... -- Hal Daume III "Computer science is no more about computers | hdaume@isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume On 23 Apr 2002, Alastair Reid wrote:
"#Hal" == Hal Daume <hdaume@ISI.EDU> writes:
I'm developing my package "NLP" for supporting common NLP functions and have a set of functions/datatypes that are common to almost all of my modules and I wanted to separate them off into an "NLP.Prelude" file, but this seems not to work. One of my modules imports Prelude (the Haskell one) directly so I can hide a few definitions, but then it looks at NLP/Prelude.lhs and complains that the name of that module "NLP.Prelude" doesn't match "Prelude". SHould I simply name my module "NLP.NLPPrelude" or something (which is ugly, imo) or what?
The only change that hierarchial module namespaces make is that the dots become a legal part of the name and that compilers have a sensible way of mapping them onto filenames such as replacing dots by slashes. So, under the new scheme, these names are different and unrelated
Prelude NLP.Prelude User.Hal.Daume.NLP.Prelude
in the same way that these names were different and unrelated in the old scheme.
Prelude NLP_Prelude User_Hal_Daume_NLP_Prelude
If you are seeing something other than that, the problem is with your compiler or the way you are using command line arguments to your compiler (e.g., Hugs' import chasing mechanism has some interesting interactions with hierarchial namespaces) and you should say which one you're using and how you're using it.
-- Alastair Reid