Revival: PROPOSAL: Literate haskell and module file names

[Merijn Verstraaten]

Ola!

I raised this proposal earlier this year and got to busy to follow up, this week I was suddenly reminded and decided to reraise this. To summarise the discussion up until this point:

There was no real opposition to the general idea, the only real objection to the original proposal was that “Foo.lhs.md” and “Foo.md.lhs” would collide with the naming scheme used by JHC on case insensitive filesystems. Alternative proposal raised during the discussion: "Foo+md.lhs", "Foo.lhs+md” and “Foo.md+lhs”. 

According to MS documentation and testing the + should not be an issue on windows, the + doesn’t collide with any other haskell compiler (at least, not any I’m aware off) and since the report doesn’t specify any module name resolution mechanism, it does not conflict with the report either.

My personal preferences goes to either “.lhs+md” or “.md+lhs”, since GHC currently tries every alternative in turn, I propose to just extend this list to look for any file whose extension is “.lhs+*” or “.*+lhs”.

Are there any objections to this? If not, I’m just going to produce a patch + ticket as there were no real objections to the proposal last time.

Cheers,
Merijn

On 16 Mar 2014, at 05:56 , Merijn Verstraaten <merijn at inconsistent.nl> wrote:
> Ola!
> 
> I didn't know what the most appropriate venue for this proposal was so I crossposted to haskell-prime and glasgow-haskell-users, if this isn't the right venue I welcome advice where to take this proposal.
> 
> Currently the report does not specify the mapping between filenames and module names (this is an issue in itself, it essentially makes writing haskell code that's interoperable between compilers impossible, as you can't know what directory layout each compiler expects). I believe that a minimal specification *should* go into the report (hence, haskell-prime). However, this is a separate issue from this proposal, so please start a new thread rather than sidetracking this one :)
> 
> The report only mentions that "by convention" .hs extensions imply normal haskell and .lhs literate haskell (Section 10.4). In the absence of guidance from the report GHC's convention of mapping module Foo.Bar.Baz to Foo/Bar/Baz.hs or Foo/Bar/Baz.lhs seems the only sort of standard that exists. In general this standard is nice enough, but the mapping of literate haskell is a bit inconvenient, it leaves it completelyl ambiguous what the non-haskell content of said file is, which is annoying for tool authors.
> 
> Pandoc has adopted the policy of checking for further file extensions for literate haskell source, e.g. Foo.rst.lhs and Foo.md.lhs. Here .rst.lhs gets interpreted as being reStructured Text with literate haskell and .md.lhs is Markdown with literate haskell. Unfortunately GHC currently maps filenames like this to the module names Foo.rst and Foo.md, breaking anything that wants to import the module Foo.
> 
> I would like to propose allowing an optional extra extension in the pandoc style for literate haskell files, mapping Foo.rst.lhs to module name Foo. This is a backwards compatible change as there is no way for Foo.rst.lhs to be a valid module in the current GHC convention. Foo.rst.lhs would map to module name "Foo.rst" but module name "Foo.rst" maps to filename "Foo/rst.hs" which is not a valid haskell module anyway as the rst is lowercase and module names have to start with an uppercase letter.
> 
> Pros:
> - Tool authors can more easily determine non-haskell content of literate haskell files
> - Currently valid module names will not break
> - Report doesn't specify behaviour, so GHC can do whatever it likes
> 
> Cons:
> - Someone has to implement it
> - ??
> 
> Discussion: 4 weeks
> 
> Cheers,
> Merijn
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.haskell.org/pipermail/haskell-prime/attachments/20140815/cf39d6b9/attachment.sig>