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 <mer...@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.holzensp...@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-boun...@haskell.org> > namens Merijn Verstraaten <mer...@inconsistent.nl> > > Verzonden: zaterdag 16 augustus 2014 00:40 > > Aan: haskell-pr...@haskell.org; glasgow-haskell-users@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 <mer...@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@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > >
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users