[ 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
[ 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. oh come on :-) most of the time you don't get to see the module name at all -- you have to keep scrolling to the top of the file. virtually every editor can tell you what is the name of the file you are editing... (:f in vim). and tools like haddoc can display the name of
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?). making them the same seems wrong. the one being an abstraction of the other does not seem all that bad. for the particular problem you raise
hi, sorry for moving this back to the haskell mailing list, but i think the module system is part of the language and is not a library. Simon Marlow wrote: this seems exactly the opposite of what all file systems do. i know lateral thinking is great, but why do we have to be backwards all the time? the module anyways. the meaning of modules can still be independent of the mapping between modules and filesnames. all that has to be specified is how to compute this mapping. and one has to do that anyways, even if the haskell report pretends that this can be ommited. in fact this is exactly what the initial poster was asking. this whole issue about realtive/absoulte paths is part of specifying the mapping between module names and file names. in fact if one decides to ignore this mapping, all that the "hirarchical modules" proposal does is allow one to write "." in a module name. if one wants to keep modules and file names comletely independent it seems that one should introduce some notion of a "project" or something, which specifies the above mentioned mapping. however i am not sure that the additional flexibility of such an approach would be useful, and i would be perfectly happy with a single fixed way to compute the maping between modules and files. there are at least two more or less obvious choices: * disallow single quotes in module names (but not necessarily module name aliases) * say what should single quote be mapped to in the file system (e.g. _) i like the first one better. what does GHC do in this situation? bye iavor -- ================================================== | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | ==================================================
participants (2)
-
Iavor S. Diatchki -
Simon Marlow