Problem with hierarchical libraries in Hugs compared to ghc/nhc98
Fri, 14 Mar 2003 14:19:08 +0000
> 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:
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).