Problem with hierarchical libraries.

[Iavor S. Diatchki]

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:
> [ 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).
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?


> 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 
the module anyways.


>>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.
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.

> 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 
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               |
==================================================