caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Tom Ridge <tom.j.ridge+caml@googlemail.com>
To: "Daniel Bünzli" <daniel.buenzli@erratique.ch>
Cc: caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] First release of P3: a combinator parser library, and parser generator
Date: Mon, 8 Apr 2013 12:33:28 +0100	[thread overview]
Message-ID: <CABooLwMvqgTy6WP14dbK38TYKkLOV7wmxuP3X0fXWOYfWGG23A@mail.gmail.com> (raw)
In-Reply-To: <48620B658D39465385431EB23E6876C8@erratique.ch>

[-- Attachment #1: Type: text/plain, Size: 1614 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2195 bytes --]

  reply	other threads:[~2013-04-08 11:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-08 10:28 Tom Ridge
2013-04-08 11:03 ` Daniel Bünzli
2013-04-08 11:33   ` Tom Ridge [this message]
2013-04-08 12:29     ` Daniel Bünzli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CABooLwMvqgTy6WP14dbK38TYKkLOV7wmxuP3X0fXWOYfWGG23A@mail.gmail.com \
    --to=tom.j.ridge+caml@googlemail.com \
    --cc=caml-list@inria.fr \
    --cc=daniel.buenzli@erratique.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).