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

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 see those too structures as different entities. Why can't I coalesce two tiny modules into a single file? I also don't like having to capitalize my file names (Foo.hs instead of foo.hs) in linux, that seems rather ugly. It see this "ugliness" as a symptom of the "arbitrarily forced link" between the module structure and the file structure. Obviously, some conventions should apply, but a one-to-one correspondence seems too strict. Dimitri -- 2E45 D376 A744 C671 5100 A261 210B 8461 0FB0 CA1F

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. 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...

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

On Mon, Dec 19, 2016 at 2:22 PM, MarLinn via Haskell-Cafe < haskell-cafe@haskell.org> wrote:
If we want our language to remain extensible and at the forefront of language development, we can't tie down too many parts.
I think this is an excellent point. One of the distinguishing features of Haskell is that, as a language, it makes almost no concessions to the underlying architecture on which it is compiled or eventually run (and, impressively, manages to achieve very good performance and usability anyway!). Haskell, among all production languages, is perhaps the only one that would be equally at home on some sort of alien lambda-machine as it would on an x86 processor (i.e. not very, but Haskell's foundations are solid enough that we could make it work well). More practically, one could imagine that someone might like to use Haskell as e.g. some sort of cloud-based scripting language where the notion of a filesystem hierarchy doesn't make a lot of sense. There's no good reason to force the language to adhere to something as arbitrary or restricted as a traditional filesystem hierarchy. "Modules" are a much more general concept than files on a disk, and it would be a mistake to over-specify them. Cheers, Will

On Mon, Dec 19, 2016 at 2:22 PM, MarLinn via Haskell-Cafe < haskell-cafe@haskell.org> wrote: There's no good reason to force the language to adhere to something as arbitrary or restricted as a traditional filesystem hierarchy. "Modules" are a much more general concept than files on a disk, and it would be a mistake to over-specify them.
It is already the case that Haskell identifiers (including module names) are case sensitive, and some popular file systems are not, making tying to a file system dodgy. In attempt to solve a similar problem, SGML introduced the idea of "entities". SGML chunks are stored as "entities" managed by an "entity manager" which might or might not be some sort of file system. OASIS introduced the idea of "catalogs" which allow entity names to be mapped in various ways. I don't see any reason why, for example, a Haskell compiler couldn't map Foo.Bar.Ugh to Foo.zip(Bar/Ugh.hs) if so directed.

On 19 Dec 2016, at 22:22, William Yager wrote:
There's no good reason to force the language to adhere to something as arbitrary or restricted as a traditional filesystem hierarchy. "Modules" are a much more general concept than files on a disk, and it would be a mistake to over-specify them.
And this is exactly why Haskell, the language, leaves this open. There is no forced mapping between module names and their file storage. That is an implementation matter, left to individual compilers. In the past, there has been at least one conformant Haskell compiler which allowed multiple modules to live in the same file. Regards, Malcolm
participants (6)
-
Dimitri DeFigueiredo
-
Malcolm Wallace
-
MarLinn
-
ok@cs.otago.ac.nz
-
Sven Panne
-
William Yager