On 2016-12-19 18:24, Sven Panne wrote:
2016-12-19 17:38 GMT+01:00 Dimitri DeFigueiredo:
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.
[…]
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.
[…]
I haven't heard a single compelling *technical* reason for doing it differently up to now...
That's because it's not (purely) a technical issue. I think the resistance comes mostly from a more philosophical point of view: If we want our language to remain extensible and at the forefront of language development, we can't tie down too many parts. That includes our module system. Granted: the module system is not what the language is known for right now. But maybe we do want our equivalents to friend classes, extension classes, or multimethods one day, or we might even find that there's a natural way to separate "normal" definitions from instance declarations that is less ugly than orphans or overlapping. Or maybe we realize that all scopes are basically equivalent anyway, from function bodies up to whole modules – so why separate them syntactically. What I'm getting at is not that the mere possibility of such developments should prevent us from trying to find good mid-term solutions. But after all, Haskell was originally conceived as a research language. Even if this type of modularization is not a well-studied topic and mostly solved in an ad-hoc manner in practice, that shouldn't prevent us from leaving the door open at least a bit. The next question then is: How *do* we combine both view points? Especially, how do we do it efficiently?
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.
I think the key word here is "a". As in *a* spec, not *the* spec or *the* report. One spec for each discovery-strategy, easy to find, easy to reference. That makes it trackable like any other dependency. And if there is a spec, translating it into code is almost mechanical, and must only be done once per (tool,spec) pair at most. Of course I'm simplifying a lot, not least because I'm not a tool-maker. So this is only how far I can see from my hermit tower at the moment. Cheers, MarLinn