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

[Simon Peyton Jones]

Marijn,

Thanks.  Can you make sure that you update the wiki page to reflect what you say here?  Email is transitory; the wiki page gives the *specification* of the feature, and says unambiguously what you intend.  Misunderstandings expressed in email are simply tell you how to improve the wiki page!

thanks

Simon

| -----Original Message-----
| From: Merijn Verstraaten [mailto:merijn at inconsistent.nl]
| Sent: 16 November 2014 21:42
| To: Simon Peyton Jones
| Cc: ghc-devs at haskell.org; GHC Users Mailing List
| Subject: Re: More flexible literate Haskell extensions (Trac #9789),
| summary on wiki
| 
| 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