GoogleCodeExporter
commented
8 years ago New proposal:
add to parser state: LiterateHaskellMode :: Bool -- default : False
add to writer options: LiterateHaskell :: Bool -- default : False
When parsing markdown, if
<!-- literate haskell --> or
<!-- start literate haskell --> or
<!-- begin literate haskell -->
is encountered in the source, turn on LiterateHaskellMode. Turn it off if
<!-- stop literate haskell --> or
<!-- end literate haskell -->
is encountered.
When LiterateHaskellMode is on, bird-track sections in markdown will be treated
as
code blocks with class "literatehaskell", not as quote blocks.
When parsing LaTeX, LiterateHaskellMode should activate proper handling of
\begin{code}..\end{code}, \ignore{}, etc.
When parsing HTML in LiterateHaskellMode, parse <pre> blocks with bird tracks
as code
blocks with class "literatehaskell."
On the output side:
If LiterateHaskell is on, print bird-tracks in markdown code blocks with class
"literatehaskell" (and begin the document, after the title block, with <!--
literate
haskell -->). Also print bird-tracks in HTML and use \begin{code}...\end{code}
in LaTeX.
How do these options get set?
if input file extension is ".lhs", turn on LiterateHaskellMode.
if output file extension is ".lhs", turn on LiterateHaskell in writer options.
Also add command-line options '--lhs-in' and '--lhs-out'. '--lhs' could be
equivalent to both '--lhs-in' and '--lhs-out'.
Note: I've reverted the "ignore blank line at beginning of delimited code
block"
feature mentioned in the last comment. These changes should render that kludge
unnecessary.
Original comment by fiddloso...@gmail.com on 2 Nov 2008 at 4:59
But this approach has some problems. First, if the document contains regular blockquotes, they will be treated as haskell code by GHC. Second, it is inconvenient to have to repeat the tildes and the (optional) {.haskell} annotation. Third, blank spaces are needed before and after the bird-track sections. The current SVN version of pandoc collapses this blank space, but that's not such desirable behavior in general (what if one wants a code block with leading or trailing blank lines?) (The blank-space requirement can be turned off in ghc using the flags '-optL -q', but it is not ideal to expect people to know or remember this.)
Here is a proposal. Add a new command-line flag, '--lhs', to indicate that the input file is literate haskell. (This can be turned on automatically if the extension is '.lhs'.) When '--lhs' is specified and the input format is markdown, bird-track sections are treated as code blocks (with class attribute "haskell"), not as block quotes. Indented code blocks are still treated as code blocks.
When '--lhs' is specified and the input is latex, special lhs-specific constructions are recognized (e.g. \begin{code}...\end{code}).
'--lhs' could have an effect on output as well. Obviously, for markdown output it would output haskell code blocks in bird tracks. (What about HTML output? Probably bird tracks should be used there, too, so people could cut and paste from the HTML and have valid lhs.)