Why not use uu-parsinglib, which will tell you what is wrong and nevertheless
will continue parsing?
Currently Jacco Krijnen is working on an extensible version of Pandoc, based on
the AspectAG and the Murder packages, so you can define your own plugins for
syntax and semantics.
Doaitse Swi
On 31/07/2013, at 8:16 PM, Simon Hengel wrote:
>
> * There is no such thing as a parse error in Markdown, and I think we
> should try to make this true for Haddock markup, too
It is very far from clear that this is a virtue in Markdown.
In trying to learn Markdown, I found it an excessively ti
Hi Roman,
> However, the decision to use Attoparsec (instead of Parsec, say)
> strikes me as a bit odd, as it wasn't intended for parsing source
> code. In particular, I'm concerned with error messages this parser
> would produce.
In addition to what Mateusz already said, I want to briefly summar
On 31/07/13 08:21, Mats Rauhala wrote:
> Is Data.Text as an extra dependency really that bad? Remember that you
> are parsing comments, prose, human produced text, where Data.Text is way
> more useful than ByteString.
>
It has to come with GHC boot packages and it currently doesn't. I have
updated
Is Data.Text as an extra dependency really that bad? Remember that you
are parsing comments, prose, human produced text, where Data.Text is way
more useful than ByteString.
--
Mats Rauhala
MasseR
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
h
On 31/07/13 06:37, Roman Cheplyaka wrote:
> Hi Mateusz,
>
> This looks great — I'm especially excited about "List entries no longer
> have to be separated by empty lines"!
Glad to hear that.
>
> However, the decision to use Attoparsec (instead of Parsec, say) strikes
> me as a bit odd,
Parsec has
Hi Mateusz,
This looks great — I'm especially excited about "List entries no longer
have to be separated by empty lines"!
However, the decision to use Attoparsec (instead of Parsec, say) strikes
me as a bit odd, as it wasn't intended for parsing source code. In
particular, I'm concerned with erro