RE: Problem with hierarchical libraries in Hugs compared to ghc/nhc98
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.
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.
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 "."). Cheers, Simon
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
On Fri, Mar 14, 2003 at 02:04:08PM -0000, Simon Marlow wrote:
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.
[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.
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
On Sat, Mar 22, 2003 at 01:39:16PM -0500, Henrik Nilsson wrote:
To re-iterate, my basic argument 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.
OK, you're arguing for a much more flexible relationship between filenames and module names. But is the very limited form offered by Hugs (A.B.C -> A.B.C.hs or A/B/C.hs) of any use as is? Do you use it?
participants (4)
-
Alastair Reid -
Henrik Nilsson -
Ross Paterson -
Simon Marlow