<div dir="ltr">On Mon, Dec 19, 2016 at 2:22 PM, MarLinn via Haskell-Cafe <span dir="ltr"><<a href="mailto:haskell-cafe@haskell.org" target="_blank">haskell-cafe@haskell.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If we want our language to remain extensible and at the forefront of language development, we can't tie down too many parts. </blockquote><div><br></div><div>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!).</div><div><br></div><div>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).</div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div>Will</div></div></div></div>