Make GHC accept .format+lhs as extension for literate haskell files

I proposed this solution on the mailing list as a solution to allowing other tools to determine what the type of the non-haskell content in a literate haskell file is. For example, whether a document is markdown + literate haskell or reStructuredText + literate haskel.

There were no real objections on the mailing list and this approach has been tested and works on Windows.

Last discussion: https://www.haskell.org/pipermail/glasgow-haskell-users/2014-August/025228.html Initial discussion: https://www.haskell.org/pipermail/glasgow-haskell-users/2014-March/024745.html

Trac metadata

Trac field	Value
Version	7.9
Type	FeatureRequest
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed weight to 5

added Tfeature request Trac import labels

Some hopefully constructive comments:

• This proposal could use a wikipage I think. It would describe the problem being addressed, the different proposals that were made, and why this solution was chosen (accepting .format+lhs as a file extension).
• Maybe some combination of -o and -x command line options could be used to get the same effect?
• This mail (proposing .hs.format) and this one (prososing a textual fingerprint in the module itself) never got a reply.
• How does this feature interact with boot files: "Currently, if you use a literate source file A.lhs you must also use a literate boot file, A.lhs-boot; and vice versa."
• How does this change affect other compilers (JHC was mentioned)?
• Would this change need to go into a feature language report? Is it a language feature, does it need a flag? (I'm just trying to think if this change is a big deal or not, maybe I am overthinking things.)

Some more points:

• Does this break any tools that expect a "normal" file extension (i.e. file.lhs), like maybe Github's linguist?
• Would filepath need to be made aware of this change? Currently:

System.FilePath> takeExtension "file.format+lhs"
".format+lhs"

Thanks for the comments.

Replying to [ticket:9789#comment:90951 thomie]:

• This proposal could use a wikipage I think. It would describe the problem being addressed, the different proposals that were made, and why this solution was chosen (accepting .format+lhs as a file extension).

Given the lack of objection the two times this was raised on the mailing list and the triviality of the implementation, I didn't think a separate write-up was necessary, but I'll add one and raise this again on the mailing list.

• Maybe some combination of -o and -x command line options could be used to get the same effect?

This seems like it'd be tricky if people have repositories containing files with different content and in general a bit of a hassle, but it would probably work.

• This mail (proposing .hs.format) and this one (prososing a textual fingerprint in the module itself) never got a reply.

Hmm, you're right that .lhs.format should work, since the lack of .lhs suffix should avoid it from colliding with JHC's naming. I don't think the textual fingerprint in the module itself is a good option, as not all formats may allow for this.

• How does this feature interact with boot files: "Currently, if you use a literate source file A.lhs you must also use a literate boot file, A.lhs-boot; and vice versa."

As-is I was simply planning to map the boot file for "lhs+md" to "lhs+md-boot".

• How does this change affect other compilers (JHC was mentioned)?

The report does not specify any specific way of mapping modules to filenames and as such there is no way to make name resolution portable across compilers anyway. My initial email suggested standardising/formalising naming in the report, but this was not taken up.

• Would this change need to go into a feature language report? Is it a language feature, does it need a flag? (I'm just trying to think if this change is a big deal or not, maybe I am overthinking things.)

See previous point, the report explicitly does *not* specify the naming of files/modules and as such GHC can implement whatever it likes.

Replying to [ticket:9789#comment:90953 thomie]:

• Does this break any tools that expect a "normal" file extension (i.e. file.lhs), like maybe Github's linguist?

I would not call this "breaking tools" as the old .lhs extension will remain supported by GHC. I would merely say that not all tools may immediately *support* this new format. However, it seems unlikely tools will change to match a format until GHC implements (i.e., chicken and egg problem). I think GHC should just implement a solution that will be easy for other tools to follow.

• Would filepath need to be made aware of this change? Currently:

System.FilePath> takeExtension "file.format+lhs"
".format+lhs"

No, I consider ".format+lhs" to be the extension. This would only change the way GHC searched for modules.

More discussion https://www.haskell.org/pipermail/ghc-devs/2014-November/007319.html

Proposal wiki page: https://ghc.haskell.org/trac/ghc/wiki/FlexibleLiterateExtension

added Pnormal label