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:mer...@inconsistent.nl] | Sent: 16 November 2014 21:42 | To: Simon Peyton Jones | Cc: ghc-devs@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 <simo...@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 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
