* This proposal could use a [wiki:WorkingConventions/AddingFeatures wiki
#9789: Make GHC accept .format+lhs as extension for literate haskell files -------------------------------------+------------------------------------- Reporter: merijn | Owner: merijn Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by merijn): Thanks for the comments. Replying to [comment:1 thomie]: page] 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 [https://www.haskell.org/ghc/docs/7.8.3/html/users_guide/modes.html #overriding-suffixes -x] command line options could be used to get the same effect?
* This [https://www.haskell.org/pipermail/glasgow-haskell- users/2014-March/024757.html mail] (proposing `.hs.format`) and [https://www.haskell.org/pipermail/glasgow-haskell- users/2014-March/024747.html this one] (prososing a textual fingerprint in
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. 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 [https://www.haskell.org/ghc/docs/latest/html/users_guide/separate- compilation.html 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.)
* Does this break any tools that expect a "normal" file extension (i.e. file.lhs), like maybe Github's [https://github.com/github/linguist
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 [comment:2 thomie]: 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. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9789#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler