Revival: PROPOSAL: Literate haskell and module file names
Carter Schonwald
carter.schonwald at gmail.com
Sat Aug 16 21:23:58 UTC 2014
i personally think the .format+lhs pattern/convention is a good one, and
prevents any misinterpretations that current plague literate tools + willl
be treated as an unknown format rather than eagerly as .format or .lhs
On Sat, Aug 16, 2014 at 5:05 PM, Merijn Verstraaten <merijn at inconsistent.nl>
wrote:
> Hey Philip,
>
> This proposal is not because *GHC* needs to know anything about
> markdown/rST, in fact, GHC is already perfectly happy to take a literate
> haskell files that’s written in markdown, since it just strips the
> non-haskell bits and only compiles the haskell code.
>
> The problem is OTHER tools. For example, I have literate haskell files for
> my blog posts, how does my blog software know whether my lhs file is
> markdown, rST, TeX, or what not? I can just name my files using anyway I
> want (like “Foo.md.lhs”) to have these tools detect the format, but then
> GHC will no longer compile my files.
>
> This is the problem I’m trying to solve with this proposal, once we settle
> on some extension format like this, it’s trivial to patch (for example)
> pandoc to use this to detect which contents are in the file.
>
> Cheers,
> Merijn
>
>
> On 16 Aug 2014, at 06:51 , p.k.f.holzenspies at utwente.nl wrote:
> > Dear Merijn,
> >
> > Do you even need a separate extension or filename convention for this?
> Can't you just call it lhs and expand the definition thereof to include
> markdown? (I suggested something similar before, but objections were raised
> that having too good and too broad an unlitter might lead to the bit-rot of
> the flag to employ external unlitters. I didn't quite understand that
> objection, but didn't pursue it)
> >
> > Regards,
> > Philip
> >
> >
> > ________________________________________
> > Van: Glasgow-haskell-users <glasgow-haskell-users-bounces at haskell.org>
> namens Merijn Verstraaten <merijn at inconsistent.nl>
> > Verzonden: zaterdag 16 augustus 2014 00:40
> > Aan: haskell-prime at haskell.org; glasgow-haskell-users at haskell.org
> > Onderwerp: Revival: PROPOSAL: Literate haskell and module file names
> >
> > 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
> >>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140816/599c606e/attachment-0001.html>
More information about the Glasgow-haskell-users
mailing list