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-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.
