[ moved to libraries@haskell.org ]
why not fix the design to take this into account? one can have two ways to refer to modules - relative and absolute (just like in the file system, which years of experience show works pretty well).
import .Test.A -- refers to an absolute path -- (relative to a user specified root) -- i.e. $HS_PATH/Test/A.hs import Test.A -- is a path relative to the location of -- the current module, i.e. -- [location of module]/Test/A.hs
IIRC, something very similar was suggested a while back on the libraries list, except that the form beginning with a dot was the relative module name (actually I think I prefer it that way). Personally, I've been using the hierarchical module names for a while and I really don't mind writing out the whole name each time. It means you have less context to think about when reading the source.
i also have another question about the hirarchical modules design -- why does one have to duplicate the path to a particular file inside the file itself? i.e. what is the point of the module name within the file? it seems that all haskell implementations assume that the module name and file name are the same (and this seems perfectly reasonable), and with the hirarchical name space this is even more the case. and for example C programers never specify the name of the current file within the file. why do we want to do it?
This arises because the meaning of a module is defined independently of the mapping between modules and filenames. I agree that this leads to some redundancy, and it can be annoying that moving modules from one place in the hierarchy to another requires editing the source. Building knowledge of the filesystem into the spec is the wrong thing to do, given that filesystems tend to have platform-specific differences (eg. single quote is allowed in a module name - is it allowed in a filename? on which operating systems?). There are other approaches - perhaps defining a module as a pair of a module name and module text, where the compiler is free to infer the module name from other information it is supplied. But personally, I'm not convinced it's that big a problem. Cheers, Simon