Problem with hierarchical libraries.

[Simon Marlow]

[ moved to libraries@haskell.org ]

> why not fix the design to take this into account?  one can=20
> have two ways=20
> to refer to modules - relative and absolute (just like in the file=20
> system, which years of experience show works pretty well).
>=20
> 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=20
> design -- why=20
> does one have to duplicate the path to a particular file=20
> inside the file=20
> 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=20
> and file name are the same (and this seems perfectly reasonable), and=20
> with the hirarchical name space this is even more the case.  and for=20
> example C programers never specify the name of the current=20
> file within=20
> 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. =20

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