[Haskell-cafe] Foo.Bar.hs filenames poll
monkleyon at googlemail.com
Mon Dec 19 21:22:44 UTC 2016
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.
More information about the Haskell-Cafe