Problem with hierarchical libraries in Hugs compared to ghc/nhc98

[Alastair Reid]

> I don't quite follow you.  The issue as I see it is whether a module
> A.B.C can be placed in a file A.B.C.hs, or whether it has to be
> named A/B/C.hs (substitute / for the local directory separator).
> IIRC some people wanted to be able to do this - I suppose it might
> be useful to avoid deep/sparse directory structures.

Except on systems which don't have recursive directories, I don't see
any motivation to be able to do this.

If we allow A.B.C to be mapped to either A.B.C.hs or A/B/C.hs,
shouldn't we also allow:

  A.B/C.hs
  A/B.C.hs

I think we'd soon be asked to do this for consistency and I'd rather
not support all those options - much better to have module names map
onto filenames in a small number of ways.

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

> How is that different from adding the current directory to the
> search path?  (which is what GHC does by default).

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

> by "current directory" you mean "directory in which the current
> module resides?"  (i.e. not the same as the meaning of ".").

Yes.  And I think that's where the difference lies.

Adding the current working directory (".") doesn't bother me - users
can choose to put it in their search path (or Hugs/ghci can implicitly
add it for them).

--
Alastair