|
|
# Flexible Literate Haskell File Extensions
|
|
|
|
|
|
|
|
|
Literate haskell files currently contain two (or more?) types on content, but the current `.lhs` extension doesn't offer tools any insight what the non-haskell content of a file is. This is problem when, for example, using Pandoc to convert literate haskell files into other documents. The goal of this proposal is to give other tools the information they need to figure out what the non-haskell content of a file is. This issue was raised two times on the mailing list ([ https://www.haskell.org/pipermail/glasgow-haskell-users/2014-March/024745.html](https://www.haskell.org/pipermail/glasgow-haskell-users/2014-March/024745.html) and [ https://www.haskell.org/pipermail/glasgow-haskell-users/2014-August/025228.html](https://www.haskell.org/pipermail/glasgow-haskell-users/2014-August/025228.html) respectively) and the corresponding Trac ticket [9789](https://gitlab.haskell.org//ghc/ghc/issues/9789).
|
|
|
Literate haskell files currently contain two (or more?) types on content, but the current `.lhs` extension doesn't offer tools any insight what the non-haskell content of a file is. This is problem when, for example, using Pandoc to convert literate haskell files into other documents. The goal of this proposal is to give other tools the information they need to figure out what the non-haskell content of a file is. This issue was raised two times on the mailing list ([https://www.haskell.org/pipermail/glasgow-haskell-users/2014-March/024745.html](https://www.haskell.org/pipermail/glasgow-haskell-users/2014-March/024745.html) and [https://www.haskell.org/pipermail/glasgow-haskell-users/2014-August/025228.html](https://www.haskell.org/pipermail/glasgow-haskell-users/2014-August/025228.html) respectively) and the corresponding Trac ticket [9789](https://gitlab.haskell.org//ghc/ghc/issues/9789).
|
|
|
|
|
|
|
|
|
This page aims to summarise the results of the previous discussion and clarify the impact of the proposal, as requested by thomie.
|
... | ... | @@ -42,7 +42,7 @@ Some concerns raised during the earlier discussion: |
|
|
The original proposal's `Foo.md.lhs` suggestion works well with GHC, but is not very portable to other compilers. While GHC maps the module name `Foo.Bar.Baz` to the path `Foo/Bar/Baz.hs`, other compilers, however, use different schemes, for example JHC can map the `Foo.Bar.Baz` module name to the file `Foo.Bar.Baz.hs`. This would not be a problem since haskell does not allow lowercase module names, so `Foo.md.lhs` would not be a valid module. Unfortunately GHC is also used on platforms that have a case-insensitive filesystem, where this approach breaks.
|
|
|
|
|
|
|
|
|
Another concern for the various `+` variants was whether this is legal on windows. The Microsoft documentation ([ http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx](http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx)) does not specify `+` as a restricted character and testing shows these are legal on Windows.
|
|
|
Another concern for the various `+` variants was whether this is legal on windows. The Microsoft documentation ([http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx](http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx)) does not specify `+` as a restricted character and testing shows these are legal on Windows.
|
|
|
|
|
|
|
|
|
The question how this change interacts with other compilers and the Haskell Report was raised. The haskell report (perhaps unwisely) does not specify the mapping of module names to filenames, and is therefore a non-issue for this change. Given the lack of standardisation there is no way to rely on portability between compilers in existing haskell anyway. The proposal tries to avoid conflicts with other compilers were possible and there, currently, are no known conflicts between this change and existing compilers.
|
... | ... | |