[Haskell-cafe] Foo.Bar.hs filenames poll
Sven Panne
svenpanne at gmail.com
Mon Dec 19 17:24:00 UTC 2016
2016-12-19 17:38 GMT+01:00 Dimitri DeFigueiredo <defigueiredo at ucdavis.edu>:
> I believe it is a mistake to tie the module structure of a software
> system to a file structure on a hierarchical file system. [..]
I think it's not a mistake, it's the only sane thing to do in the current
tooling ecosystem. Try e.g. writing a correct Makefile without a 1:1
correspondence, and you will end up with either something shell-script like
or miss some dependencies. As an exercise, try something like this for e.g.
Java where there is no 1:1 correspondence between the source files and the
build artifacts. OK, the compiler knows the dependencies when trying to
compile things, but that is basically the only tool which is 100% correct.
But this doesn't really help when writing Makefiles, because you can't even
see the e.g. dependencies of a .class file (the compiler inlines e.g.
"static final int"s without a trace where they came from). The situation in
the Haskell world is not much different: Yes, "ghc --make" knows how to do
its task, but integrating this into a project where Haskell compilation is
only a part is not easy or ends up in something non-declarative
shell-script-like.
To be honest: I can't really understand all of this discussion. It would be
great if the status quo of a mapping between hierarchical names and a
directory hierarchy would end up in a spec, so it is *the* way to do it.
Doing things in exactly one way frees up the mind from figuring out useless
details, in this case based only on personal taste. I haven't heard a
single compelling *technical* reason for doing it differently up to now...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20161219/9d625cb9/attachment.html>
More information about the Haskell-Cafe
mailing list