Right, given the lack of disagreement and past support for this I will implement whichever variant is simplest to implement/strikes my fancy and put a patch up on Trac.
Cheers, Merijn On 16 Aug 2014, at 14:23 , Carter Schonwald <carter.schonw...@gmail.com> wrote: > 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-prime@haskell.org; glasgow-haskell-us...@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-us...@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
