[Haskell-cafe] Foo.Bar.hs filenames poll

[MarLinn]

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