From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id B00B57EE51 for ; Mon, 8 Apr 2013 13:34:04 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of tom.j.ridge@googlemail.com) identity=pra; client-ip=74.125.82.179; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="tom.j.ridge@googlemail.com"; x-sender="tom.j.ridge@googlemail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of tom.j.ridge@googlemail.com designates 74.125.82.179 as permitted sender) identity=mailfrom; client-ip=74.125.82.179; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="tom.j.ridge@googlemail.com"; x-sender="tom.j.ridge@googlemail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-we0-f179.google.com) identity=helo; client-ip=74.125.82.179; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="tom.j.ridge@googlemail.com"; x-sender="postmaster@mail-we0-f179.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgCAMuqYlFKfVKzjmdsb2JhbABRxWMIFg4BAQEBBw0JCRIGJIIfAQEEAUABATcBBAsBCgQHOyISAQUBHAYTCId5AQMJBp5tim+EOwEFg30KGScNiVcGkmuWd48sFimBWYEfgTc7 X-IPAS-Result: AhgCAMuqYlFKfVKzjmdsb2JhbABRxWMIFg4BAQEBBw0JCRIGJIIfAQEEAUABATcBBAsBCgQHOyISAQUBHAYTCId5AQMJBp5tim+EOwEFg30KGScNiVcGkmuWd48sFimBWYEfgTc7 X-IronPort-AV: E=Sophos;i="4.87,431,1363129200"; d="scan'208";a="12270693" Received: from mail-we0-f179.google.com ([74.125.82.179]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 08 Apr 2013 13:33:49 +0200 Received: by mail-we0-f179.google.com with SMTP id p43so4415512wea.24 for ; Mon, 08 Apr 2013 04:33:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=XTsR7u23QxQwkatjA7dhYbsYwjOjsbr1px2f9qfdKhk=; b=rNemDmXUonsMtcgwdaFWe7vl5KHhIC0N2mhyhg8v+5UQOnjjxavfZ4TUcCVQNfNkO6 PHmCAgLg8kv7cfRdjfgsnrJoIW0i3s/69onkV5EvqMN7RI2RhkzVYU5uoow6jvRdJqUd t8D8KNv+H9M6xVEXpIKq6jDibgTcx0jrvSAXitfX2MaM9n/yJOufTW6C0MMYPZ3wgL3L B6xL5UnY+SvIDNPr+Lb1gGoRlJnw0Ztkd/lCASMVcBZc+o4Pw4QC3A8kldwpr+haPSKq 0VS6A9llSubFuSLODJ4VXrH2xNkFs9p2mvpvNwnLjB2rJ9pLq/as1RdAt1L2JLFjauHb XcEQ== X-Received: by 10.180.84.162 with SMTP id a2mr12197713wiz.14.1365420828627; Mon, 08 Apr 2013 04:33:48 -0700 (PDT) MIME-Version: 1.0 Sender: tom.j.ridge@googlemail.com Received: by 10.180.38.71 with HTTP; Mon, 8 Apr 2013 04:33:28 -0700 (PDT) In-Reply-To: <48620B658D39465385431EB23E6876C8@erratique.ch> References: <48620B658D39465385431EB23E6876C8@erratique.ch> From: Tom Ridge Date: Mon, 8 Apr 2013 12:33:28 +0100 X-Google-Sender-Auth: 4A_K9kw-uYUTRUiwQLsAwECwSmc Message-ID: To: =?ISO-8859-1?Q?Daniel_B=FCnzli?= Cc: caml-list Content-Type: multipart/alternative; boundary=f46d044271947597ec04d9d7cf97 Subject: Re: [Caml-list] First release of P3: a combinator parser library, and parser generator --f46d044271947597ec04d9d7cf97 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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=FCnzli 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 > > > --f46d044271947597ec04d9d7cf97 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
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 correctio= n (I'm not completely sure what error correction is).

* Is there support for non-blocking parsing (asynchronous IO) ?<= /div>

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 wh= o doesn't care too much about absolute performance.=A0

For large inputs, which must be parsed quic= kly 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=FCnzli= <daniel.buenzli@erratique.ch> wrote:
Hello Tom,

Combinator parsers were an obsession of mine a few years ago. I really like= d the approach but eventually always ended up writing LL(k) parsers (xmlm, = jsonm) by hand which so far has been the only "technology" that a= llows 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 corre= ction ?
* Is there support for non-blocking parsing (asynchronous IO) ?

Best,

Daniel



--f46d044271947597ec04d9d7cf97--