PROPOSAL: Literate haskell and module file names

Edward Kmett ekmett at
Mon Mar 17 13:08:01 UTC 2014

Foo+rst.lhs does nicely dodge the collision with jhc.

How does ghc do the search now? By trying each alternative in turn?

On Sun, Mar 16, 2014 at 1:14 PM, Merijn Verstraaten
<merijn at>wrote:

> I agree that this could collide, see my beginning remark that I believe
> that the report should provide a minimal specification how to map modules
> to filenames and vice versa.
> Anyhoo, I'm not married to this specific suggestion. Carter suggested
> "Foo+rst.lhs" on IRC, other options would be "Foo.rst+lhs" or
> "Foo.lhs+rst", I don't particularly care what as long as we pick something.
> Patching tools to support whatever solution we pick should be trivial.
> Cheers,
> Merijn
> On Mar 16, 2014, at 16:41 , Edward Kmett wrote:
> One problem with Foo.*.hs or even mapping to the module name Foois that as I recall JHC will look for
> Data.Vector in Data.Vector.hs as well as Data/Vector.hs
> This means that on a case insensitive file system Foo.MD.hs matches both
> conventions.
> Do I want to block an change to GHC because of an incompatible change in
> another compiler? Not sure, but I at least want to raise the issue so it
> can be discussed.
> Another small issue is that this means you need to actually scan the
> directory rather than look for particular file names, but off my head
> really I don't expect directories to be full enough for that to be a
> performance problem.
> -Edward
> On Sun, Mar 16, 2014 at 8:56 AM, Merijn Verstraaten <
> merijn at> wrote:
>> Ola!
>> I didn't know what the most appropriate venue for this proposal was so I
>> crossposted to haskell-prime and glasgow-haskell-users, if this isn't the
>> right venue I welcome advice where to take this proposal.
>> Currently the report does not specify the mapping between filenames and
>> module names (this is an issue in itself, it essentially makes writing
>> haskell code that's interoperable between compilers impossible, as you
>> can't know what directory layout each compiler expects). I believe that a
>> minimal specification *should* go into the report (hence, haskell-prime).
>> However, this is a separate issue from this proposal, so please start a new
>> thread rather than sidetracking this one :)
>> The report only mentions that "by convention" .hs extensions imply normal
>> haskell and .lhs literate haskell (Section 10.4). In the absence of
>> guidance from the report GHC's convention of mapping module Foo.Bar.Baz to
>> Foo/Bar/Baz.hs or Foo/Bar/Baz.lhs seems the only sort of standard that
>> exists. In general this standard is nice enough, but the mapping of
>> literate haskell is a bit inconvenient, it leaves it completelyl ambiguous
>> what the non-haskell content of said file is, which is annoying for tool
>> authors.
>> Pandoc has adopted the policy of checking for further file extensions for
>> literate haskell source, e.g. Foo.rst.lhs and Here .rst.lhs
>> gets interpreted as being reStructured Text with literate haskell and
>> .md.lhs is Markdown with literate haskell. Unfortunately GHC currently maps
>> filenames like this to the module names Foo.rst and, breaking
>> anything that wants to import the module Foo.
>> I would like to propose allowing an optional extra extension in the
>> pandoc style for literate haskell files, mapping Foo.rst.lhs to module name
>> Foo. This is a backwards compatible change as there is no way for
>> Foo.rst.lhs to be a valid module in the current GHC convention. Foo.rst.lhs
>> would map to module name "Foo.rst" but module name "Foo.rst" maps to
>> filename "Foo/rst.hs" which is not a valid haskell module anyway as the rst
>> is lowercase and module names have to start with an uppercase letter.
>> Pros:
>>  - Tool authors can more easily determine non-haskell content of literate
>> haskell files
>>  - Currently valid module names will not break
>>  - Report doesn't specify behaviour, so GHC can do whatever it likes
>> Cons:
>>  - Someone has to implement it
>>  - ??
>> Discussion: 4 weeks
>> Cheers,
>> Merijn
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Glasgow-haskell-users mailing list