Problem with hierarchical libraries in Hugs compared to ghc/nhc98

[Henrik Nilsson]

Ross Paterson wrote:

> [adding Henrik, because he was the one arguing for this feature]
> 
> The cost is admittedly small, but the utility seems approximately zero.
> 
> Typically people produce a package comprising a subtree of modules deep
> in the hierarchy.  They want an economical way to specify the common
> prefix, not a directory full of huge names sharing a long prefix.

Sorry for the delay, I've been away.

We've already had long discussions about this, and opinions seemed quite
divided. But there was much more to it than just keeping names short.

To re-iterate, my basic argumet was that the software developer should
have as much freedom as possible to organize his or her *sources* into
an appropriate hierarchy, because the developer is the only one who has
a full overview of all the various tools involved in a complicated project,
their specific requirements and idiosyncrasies, compatibility issues between
different compilers/interpreters, compatibility issues between different OS
platforms, and so on, or simply wishing to apply what he or she judges to be
sound judgement when it comes to organizing the sources.

Personally, I really dislike being forced to spread out what I regard
as related sources over more than one directory just to assign the right
"name" to the individual source files. I find it inconvenient and unfamiliar,
and I know I'm not alone in this. Maybe I should point out that I'm
typically not working with simple Haskell-only sources, but with a rather
more complicated environment involving more than one language and various
pre-processors. Perhaps this makes matters worse.

On a more practical note, there is also a certain amount of intereference
between these conventions and a tool like Make which for a number of reasons
is happiest with sources living "locally". Other tools, like GreenCard,
have also had trouble with the current conventions, forcing me to
adopt a "A_B_C" naming convention for GreenCard modules, and keeping
those outside the normal module hierarchy, both name-wise and
source-hierarchy-wise. Maybe that has been fixed, and it was of course
only GreenCard's fault anyway. But more flexible source hierarchy
conventions would have mitigated the problem.

Finally, note that naming and organization of *interface* files is a separate
issue that strictly is the domain of the compiler implementor, even if some
support is needed e.g. for generating Make dependences. GHC allows intereface
files to be stuffed away in a separate directory, which is a neat way to
allow the compiler to adopt naming conventions independently of the source
conventions.

/Henrik

-- 
Henrik Nilsson
Yale University
Department of Computer Science
nilsson@cs.yale.edu