Opened 5 years ago

Last modified 5 years ago

#9789 new feature request

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

Reported by: merijn Owned by: merijn
Priority: normal Milestone:
Component: Compiler Version: 7.9
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

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

Change History (5)

comment:1 Changed 5 years ago by thomie

Some hopefully constructive comments:

  • This proposal could use a wiki 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).
  • 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.)

comment:2 Changed 5 years ago by thomie

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"
    

comment:3 in reply to:  2 Changed 5 years ago by merijn

Thanks for the comments.

Replying to thomie:

  • This proposal could use a wiki 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 -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 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.

Note: See TracTickets for help on using tickets.