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 8C45E7EF5E for ; Mon, 25 Jul 2016 21:37:37 +0200 (CEST) IronPort-PHdr: 9a23:es8fSB+vAfdrX/9uRHKM819IXTAuvvDOBiVQ1KB91escTK2v8tzYMVDF4r011RmSDN2dtasP0rGH+4nbGkU4qa6bt34DdJEeHzQksu4x2zIaPcieFEfgJ+TrZSFpVO5LVVti4m3peRMNQJW2WVTerzWI4CIIHV2nbEwud7yzRNeZ1p/mn8mJuLTrKz1SgzS8Zb4gZD6Xli728vcsvI15N6wqwQHIqHYbM85fxGdvOE7B102kvpT4r9Zf9HF8svQg+sp3ezH8baA5BehUBTInPmRz7tDmswvHTCOC/GEVTmQPjxcOCAiTvz/gWZKkiTP7rO1mkASePMruSq0wXi/qu7xmTB7vkCAaHzE8+WDTzMd3ifQI81qauxVjztuMM8muP/1kc/aFcA== Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=seliopou@gmail.com; spf=Pass smtp.mailfrom=seliopou@gmail.com; spf=None smtp.helo=postmaster@mail-lf0-f45.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of seliopou@gmail.com) identity=pra; client-ip=209.85.215.45; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="seliopou@gmail.com"; x-sender="seliopou@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of seliopou@gmail.com designates 209.85.215.45 as permitted sender) identity=mailfrom; client-ip=209.85.215.45; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="seliopou@gmail.com"; x-sender="seliopou@gmail.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-lf0-f45.google.com) identity=helo; client-ip=209.85.215.45; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="seliopou@gmail.com"; x-sender="postmaster@mail-lf0-f45.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BNAgBBaZZXhi3XVdFchREGrSOGOocBhh0CgToHPBABAQEBAQEBAREBAQEICwsJGS+CMhWCFgEEARIRHQEbHQEDAQsGBQs3AgIiAREBBQEcBhMih3MBAw8Imj+BMj4xizuBaoJaBYQwChknDVSDOgEBAQEBAQEDAQEBAQEBAQEXAgYQhhqETYdBgloFmSiOb48/jmISHoEPNYI7gXMgMokNAQEB X-IPAS-Result: A0BNAgBBaZZXhi3XVdFchREGrSOGOocBhh0CgToHPBABAQEBAQEBAREBAQEICwsJGS+CMhWCFgEEARIRHQEbHQEDAQsGBQs3AgIiAREBBQEcBhMih3MBAw8Imj+BMj4xizuBaoJaBYQwChknDVSDOgEBAQEBAQEDAQEBAQEBAQEXAgYQhhqETYdBgloFmSiOb48/jmISHoEPNYI7gXMgMokNAQEB X-IronPort-AV: E=Sophos;i="5.28,420,1464645600"; d="scan'208,217";a="227912013" Received: from mail-lf0-f45.google.com ([209.85.215.45]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 25 Jul 2016 21:37:36 +0200 Received: by mail-lf0-f45.google.com with SMTP id l69so135491568lfg.1 for ; Mon, 25 Jul 2016 12:37:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=c7mm8Xg2oRaomBMdXsLmrxc8+PdDh0N96+FqoG8ptO0=; b=h6anlmZQR2IxuKF6S2hmlhxHHBLz2lZuNrPLuJ1HPSeB6B8jcmUPWh8ryMXnJ0Bmy1 PVhaKIjn2B1vDqX2r5wlosbDHP8ob6jCGUR3TBwaWOMMva3PdB05M1zMkPjfwlPVhuqO JHEgVCWP3r1TDMcHZrKdiyHHJUDJ+rjoMyjdwDozQ6c0U55FWfnclHcsBIGLbH88EdhA +k/mPGJcuCjy88U+NF/NyUunUE/LqVigGekMqP6FbkogWW1ho7f4C0ljGPV62NVfnKyR 5qxUDuM0WUfW0cnUy+3ZqmWxbg3Sc+1VbTziCBM52al889bzYOX21ZUoE3gA22IkCdM6 docA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=c7mm8Xg2oRaomBMdXsLmrxc8+PdDh0N96+FqoG8ptO0=; b=Q/iPLxRL+sAh/wxdcwWnaGFHLSEF0/Xs+44pVz7xYhTW4096lae7ATsCo2jta7aVfW zDph/gyGxXzgYPhHfQBWABOitJGNozJjIJ5/jNxXAba8+NeCWnhrMdcDNLxBugnmhR4o b016UTkI2VhK0h1ifXbuQagVG41nIJJrSx5kOE0L9Eqna4sgnoPTNlFJNZKANQSZywyQ RPuDBoWMupeUx9Kgsf43eODBGDI9/Dtd7l6NwH0YFQvscSywBBqKlWaAOy6XYhLUf+yY hlEgftCM1p4XLNSMotWMNtTJQPo1s3HWAY3pq9u/HBdoNrrzJJcNNZYtAQfbN0+WO3cW Y9wQ== X-Gm-Message-State: AEkoouuqSJRTpQIlmRUYJdv+da/pDfhg0RCIuJ/6Y9/K+yy782FN1iiOLXLulZIqN3YADFuZH5tRoV0+Y3mS3w== X-Received: by 10.25.40.138 with SMTP id o132mr7159418lfo.221.1469475455477; Mon, 25 Jul 2016 12:37:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.87.136 with HTTP; Mon, 25 Jul 2016 12:37:15 -0700 (PDT) In-Reply-To: <7DF0D33A403A4B41A5E2AAEAA6F6E06E@erratique.ch> References: <8B3345BC17954C9F8DC59E1C0AFBE09D@erratique.ch> <169BD7F8D4244E4DBEA9861FD6EDFB00@erratique.ch> <7DF0D33A403A4B41A5E2AAEAA6F6E06E@erratique.ch> From: Spiros Eliopoulos Date: Mon, 25 Jul 2016 15:37:15 -0400 Message-ID: To: =?UTF-8?Q?Daniel_B=C3=BCnzli?= Cc: OCaml Content-Type: multipart/alternative; boundary=001a1140232287b23305387aea31 Subject: Re: [Caml-list] ANN: angstrom --001a1140232287b23305387aea31 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jul 25, 2016 at 12:21 PM, Daniel B=C3=BCnzli wrote: > You are making a lot of assumptions about how the client should use the > library or what humans are supposed to tolerate=E2=80=A6 Nope, just one or two that seem pretty reasonable. First, there's not much else a client of a parser can do with those errors without breaking conceptual abstraction boundaries. Any action that a client would want to take that wasn't logging properly belongs in the parser itself. A design to the contrary would require the client of the parser to embody knowledge of the parsing process itself, which defeats modularity, reuse, and ultimately kills compositionality. So the only client assumption is that the client finds these sorts of properties desirable. Second, I'm well aware of human tolerances for feedback latency. Such topics have been making the rounds in The New York Times, pop design books, and the blogosphere for more than a decade now, so it's hardly an obscure topic. I've also built and commercialized systems for application performance management, which required a deep understanding of end-user experience, business use cases, and operational practices. The design I described has worst case failure reporting latency not exceeding the latency of a successful parse. If you're exceeding those latency tolerances at the parsing step, there is no hope of redemption for the latency of the rest of your pipeline. And these aren't even catastrophic failures. As you describe them they're, more or less, warnings. > Giving back control to the client in case of error and allow it to restart > the process allows to lift the constraints you put on the client. While such a design sometimes benefits the system _as a whole_, it certainly comes at a cost. In the case where clients are meant to explicitly handle parse errors and restart the parse _through control inversion_, the cost is the compositionality. That may be a worthwhile cost to pay in some cases, but those cases have not yet revealed themselves to me. On the other hand, Angstorm allows you to construct parsers compositionally, and reuse them in just the same way. It even allows users to design parsers that will report parse warnings, or even receive certain kinds of errors are return a decision (that the parser is designed to understand) about how to proceed. Whether or not that's a worthwhile design is another question. I would say it's not but there's no accounting for taste. For supporting composition, it's certainly better than control inversion. To bring it back, I think this discussion is focusing a bit too much on the implementation of a single Angstrom parser, rather than the capabilities of the library as a whole. Angstrom can suit the needs of many architectural styles, whether its a "direct" style or "streaming" style, or that leads to parsers that give clients fine-grained control over error recovery. It's a parser combinator library, after all. Your parsers can do whatever you design them to do, take whatever parameters they need to, and following a few rules of thumb, still deliver good performance. -Spiros E. --001a1140232287b23305387aea31 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Jul 25, 2016 at 12:21 PM, Daniel B=C3=BCnzli <= daniel.bue= nzli@erratique.ch> wrote:
You are making a lot of assumptions about how the client = should use the library or what humans are supposed to tolerate=E2=80=A6

Nope, just one or two that seem pretty reaso= nable. First, there's not much else a client of a parser can do with th= ose errors without breaking conceptual abstraction boundaries. Any action t= hat a client would want to take that wasn't logging properly belongs in= the parser itself. A design to the contrary would require the client of th= e parser to embody knowledge of the parsing process itself, which defeats m= odularity, reuse, and ultimately kills compositionality. So the only client= assumption is that the client finds these sorts of properties desirable.

Second, I'm well aware of human tolerances for feedback latency. S= uch topics have been making the rounds in The New York Times, pop design bo= oks, and the blogosphere for more than a decade now, so it's hardly an = obscure topic. I've also built and commercialized systems for applicati= on performance management, which required a deep understanding of end-user = experience, business use cases, and operational practices.

The design I described has worst case failure reporting latency no= t exceeding the latency of a successful parse. If you're exceeding thos= e latency tolerances at the parsing step, there is no hope of redemption fo= r the latency of the rest of your pipeline. And these aren't even catas= trophic failures. As you describe them they're, more or less, warnings.=
=C2=A0
Gi= ving back control to the client in case of error and allow it to restart th= e process allows to lift the constraints you put on the client.

While such a design sometimes benefits the s= ystem _as a whole_, it certainly comes at a cost. In the case where clients= are meant to explicitly handle parse errors and restart the parse=C2=A0_through control inversion_, the cost is the compositionality. That may= be a worthwhile cost to pay in some cases, but those cases have not yet re= vealed themselves to me. On the other hand, Angstorm allows you to construc= t parsers compositionally, and reuse them in just the same way. It even all= ows users to design parsers that will report parse warnings, or even receiv= e certain kinds of errors are return a decision (that the parser is designe= d to understand) about how to proceed. Whether or not that's a worthwhi= le design is another question. I would say it's not but there's no = accounting for taste. For supporting composition, it's certainly better= than control inversion.

To bring it back, I think this discussion is= focusing a bit too much on the implementation of a single Angstrom parser,= rather than the capabilities of the library as a whole. Angstrom can suit = the needs of many architectural styles, whether its a "direct" st= yle or "streaming" style, or that leads to parsers that give clie= nts fine-grained control over error recovery. It's a parser combinator = library, after all. Your parsers can do=C2=A0whatever you design the= m to do, take whatever parameters they need to, and following a few rules o= f thumb, still deliver good performance.

-Spiros E.

--001a1140232287b23305387aea31--