Problem with hierarchical libraries in Hugs compared to ghc/nhc98

Alastair Reid alastair@reid-consulting-uk.ltd.uk
Thu, 13 Mar 2003 06:00:00 +0000


Alastair writes:
> Better yet, drop the support for interpreting the '.' as anything
> but  a hierarchial module namespace separator.  That is, use this:

"Simon Marlow" <simonmar@microsoft.com> writes:
> I'm curious why you want to do that: in recent discussions on
> glasgow-haskell-users one or two people spoke up in favour of
> allowing the dotted version, and I was seriously considering adding
> it to GHC.  I can't remember all the reasons off the top of my head
> though.

Malcolm Wallace <Malcolm.Wallace@cs.york.ac.uk> writes:
> I think you misunderstand Alastair's comment.  The interpretation of
> '.'  that he suggests getting rid of is that of relative directory
> pathnames, e.g. import "../../lib/Something.hs", which is currently
> permitted in Hugs, but should no longer be necessary now that we
> hierarchical libs.

Actually, Simon understood me perfectly.  I don't see any value in the
dotted version.  There's two uses of dots in filenames: 

1) As just another character - like including a ', @, $ or whatever in
   a filename.

   I'd disallow all of these since they're not legal Haskell module
   names so they don't fit into the hierarchical naming scheme.

2) Part of either . (current directory) or .. (parent directory).

   I'd disallow these because they aren't needed now we have
   hierarchical libraries.   

   Note that the ghc-users discussion would have a quite different
   semantics from what Hugs has.  Hugs semantics is to simultaneously
   try to interpret filenames two ways: first relative to the current
   directory, and second relative to the search path.  The proposed
   semantics is to either treat it as relative to the current
   directory if it contains a leading dot or to treat it as relative
   to the search path otherwise.

--
Alastair

ps Thing to watch for in applying proposed change: runhugs should
continue to accept arbitrary filenames but they should always be
interpreted as filenames relative to the current working directory.
This is necessary so that the usual #! magic will work.