Dear Daniel,

It isn't a fully tooled parser by any stretch of the imagination! Sorry.

* What's the error handling strategy ? Is there support for error
correction ?

Yes, I need to do something here. At the moment, there is no real handling
of errors, and nothing to support error correction (I'm not completely sure
what error correction is).

* Is there support for non-blocking parsing (asynchronous IO) ?

No. :( It works on strings, which have to be fully loaded in memory. I
guess the use case I'm thinking of is a researcher who wants to quickly
knock up a parser, without worrying about fiddling around with the grammar,
to parse inputs of moderate size, and who doesn't care too much about
absolute performance.

For large inputs, which must be parsed quickly in absolute terms, I think
you have to start putting some restrictions on the grammar (and then you
are into using other tools).

Thanks



On 8 April 2013 12:03, Daniel Bünzli <daniel.buenzli@erratique.ch> wrote:

> Hello Tom,
>
> Combinator parsers were an obsession of mine a few years ago. I really
> liked the approach but eventually always ended up writing LL(k) parsers
> (xmlm, jsonm) by hand which so far has been the only "technology" that
> allows me to give the best error messages/correction, to handle
> asynchronous IO, and to remain reasonably efficient.
>
> Could you maybe comment on these points:
>
> * What's the error handling strategy ? Is there support for error
> correction ?
> * Is there support for non-blocking parsing (asynchronous IO) ?
>
> Best,
>
> Daniel
>
>
>