More flexible literate Haskell extensions (Trac #9789), summary on wiki

[Merijn Verstraaten]

Hi Simon,

Thanks for the comments. I think most of the confusion stems from people overthinking the scope of what I was proposing. I'll clear up the page a bit as it's currently conflating implementation details with semantics.

> On 14 Nov 2014, at 2:29, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> Would it be possible to have a section
>   a) describing a single alternative, as precisely as possible.

The single alternative would simply be:
If GHC tries to find the source for a module Foo and none of "Foo.hs", "Foo.lhs", "Foo.hsig" or "Foo.lhsig" are found, it will accept any file with a "Foo.lhs.*" extension, i.e., "Foo.lhs.md", "Foo.lhs.tex", etc.

>   b) saying what the effect or meaning of proposal is

The proposal does NOT modify the way GHC treats the contents of files or unlits literate haskell in anyway. While I'm in favour of supporting more literate formats, that's orthogonal to this proposal.

> For (a), is Foo.hs still ok?  Foo.lhs?  What if both exist and/or Foo.md.hs or whatever?

Yes, both "Foo.hs" and "Foo.lhs" are still ok. I don't think the manual specifies what GHC does in the case "Foo.hs" AND "Foo.lhs" both exist. But the implementation prefers extensions in the following order: "hs", "lhs", "hsig" and "lhsig". I would just add the new allowed extension behind that as lower priority than the current ones.

> For (b) what does a suffix of Foo.hs.md mean?  Presumably there is some markdown in there.  But how is it delimited?  Is md the only one proposed or are there others? Is it meant to be extensible or is there a fixed set?

See my earlier point, I do *not* intend to affect the way GHC interprets/unlits the contents of files. Pandoc is already perfectly happy to work with literate files, it just currently lacks a way to determine what the content type of the non-literate bits is. Which is what I hope to deal with here.

Cheers,
Merijn