<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-12-19 17:38 GMT+01:00 Dimitri DeFigueiredo <span dir="ltr"><<a href="mailto:defigueiredo@ucdavis.edu" target="_blank">defigueiredo@ucdavis.edu</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I believe it is a mistake to tie the module structure of a software<br>
system to a file structure on a hierarchical file system. [..]</blockquote><div><br></div><div>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.</div><div><br></div><div>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... </div></div></div></div>