From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 60ADF7EF1E for ; Sat, 23 Jul 2016 08:41:36 +0200 (CEST) IronPort-PHdr: 9a23:NXAjAx+ROF9Qof9uRHKM819IXTAuvvDOBiVQ1KB92u4cTK2v8tzYMVDF4r011RmSDN2dtqIP0rOK+4nbGkU4qa6bt34DdJEeHzQksu4x2zIaPcieFEfgJ+TrZSFpVO5LVVti4m3peRMNQJW2WVTerzWI4CIIHV2nbEwud7yzR96Z1p3rn8mJuLTrKz1SgzS8Zb4gZD6Xli728vcsvI15N6wqwQHIqHYbM85fxGdvOE7B102kvpT41NdZ/i9Ro/Ms8dJbGeW/JvxgDO9uNyk9K20++OHssBDCS0PPuipdAS0qlU9kCg7E4RXNdAP3oC/7/r5x0S+bMMmwR605Xyam7o9mUgXhlCYeKjN/+2GB2eJqi6cOixWlqlRV2YnLZsnBPvtxZbzcePsVQGNAWoBaUCkXUdD0VJcGE+dUZbUQlIL6vVZb6EbnCA== Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=bigswim@gmail.com; spf=Pass smtp.mailfrom=bigswim@gmail.com; spf=None smtp.helo=postmaster@mail-yw0-f176.google.com Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of bigswim@gmail.com) identity=pra; client-ip=209.85.161.176; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="bigswim@gmail.com"; x-sender="bigswim@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of bigswim@gmail.com designates 209.85.161.176 as permitted sender) identity=mailfrom; client-ip=209.85.161.176; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="bigswim@gmail.com"; x-sender="bigswim@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-yw0-f176.google.com) identity=helo; client-ip=209.85.161.176; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="bigswim@gmail.com"; x-sender="postmaster@mail-yw0-f176.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D5AQCmEJNXf7ChVdFdhBV8BqNiAQEBBoMyhgCNOyOFeQKBJAc7EQEBAQEBAQEBEQEBCQsLCRcxgjIEARKCFAEEARIRHQEbEgsBAwELBgUEBxodAgIiAREBBQEKEgYTCAoQh3MBAw8IDp0rgTI+MYs7gWqCWgWEIgoZJwMKVIMjAQEBAQEFAQEBAQEBARgCBhCFUoUVhG2CVIJaBYZWDJJEhhaIWII6jQGOYhIegQ8PJYQvIDKIFQEBAQ X-IPAS-Result: A0D5AQCmEJNXf7ChVdFdhBV8BqNiAQEBBoMyhgCNOyOFeQKBJAc7EQEBAQEBAQEBEQEBCQsLCRcxgjIEARKCFAEEARIRHQEbEgsBAwELBgUEBxodAgIiAREBBQEKEgYTCAoQh3MBAw8IDp0rgTI+MYs7gWqCWgWEIgoZJwMKVIMjAQEBAQEFAQEBAQEBARgCBhCFUoUVhG2CVIJaBYZWDJJEhhaIWII6jQGOYhIegQ8PJYQvIDKIFQEBAQ X-IronPort-AV: E=Sophos;i="5.28,407,1464645600"; d="scan'208,217";a="185694899" Received: from mail-yw0-f176.google.com ([209.85.161.176]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 23 Jul 2016 08:41:35 +0200 Received: by mail-yw0-f176.google.com with SMTP id r9so121794447ywg.0 for ; Fri, 22 Jul 2016 23:41:35 -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=M8rzmUaGrd2IC0wMnA9yuVybbt0MCmLsc4LUKkal67I=; b=PjoSLvw3AF1nddg9UnDJQ6nzX3SdA/jgvGYpumHrXDKHsyjRNbMPOwfEfo3dU/BPTc koloLA8eiblZViWpp3IQZWdyScEY3YxZ0A4wnZ4fxUX4Tk3K64VnAcy65bRf0u2hkxzo AukjU5jDM5GjCxzvYJ25maQB1YMlWoXr7IUMjj6LjKLfhRYluTv2O2RHSk9yLReVc3EE 4icxI7JP7x+1aL9nIrfcQP1VswrGc3ZQ2x59vW5AiqcKSz36HuP8UON5STiWCD9nITUT Jo6xntNEPAUfl0Srkeandu2J19+3BdAcGOEO5helQbgg1N3PunBLulORMbCuPKmh47aF Sosw== 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=M8rzmUaGrd2IC0wMnA9yuVybbt0MCmLsc4LUKkal67I=; b=lPCRulB5uHz0s11KMO0P0T6p23ffl+fs2GkxAlD+YYd0rh3/idnAQO34BfVT1CUB4V /izDYozLLIV5agGeAjy3RqX6fuMijJVii76lh580pomjzIXo9PHpyzaFlL0LRe2U/6Fe RbbiNa8JAFjrlTV5GJm5wImrwEaPs7jjMGsceBU65Ee+IO60kB4p9k+woyEGIGLJ8nTn FNgRpInREKjczrtsAwLzDFQlQtmqkZaWBFyW+kG6XFYDcMejag+KNikYcxd6me9NKFfj mnTSoluoqZQPZF/w86oVhNupPlQEEsJX9Uo/C1Twyww11B9hp9r+bFVYpuSAInMqrO4R W13Q== X-Gm-Message-State: AEkooutOs6GgY0SPiiQKB5Nsopnee58ybspdmwqYk552OBGpvTt84E4KzAC6htOps7WaGttjQO70bzPO2VKXEg== X-Received: by 10.13.234.139 with SMTP id t133mr6909510ywe.108.1469256093673; Fri, 22 Jul 2016 23:41:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.106.198 with HTTP; Fri, 22 Jul 2016 23:41:33 -0700 (PDT) In-Reply-To: <8B3345BC17954C9F8DC59E1C0AFBE09D@erratique.ch> References: <8B3345BC17954C9F8DC59E1C0AFBE09D@erratique.ch> From: Cole Brown Date: Sat, 23 Jul 2016 02:41:33 -0400 Message-ID: To: =?UTF-8?Q?Daniel_B=C3=BCnzli?= Cc: Spiros Eliopoulos , OCaml Content-Type: multipart/alternative; boundary=94eb2c069db08c2cab053847d779 Subject: Re: [Caml-list] ANN: angstrom --94eb2c069db08c2cab053847d779 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable it seems like such a pedantic critique would be most productively presented= off the main band, no? congrats on the release! exciting to see something like this in the ocaml world. i look forward to its continued improvement. cole On Friday, July 22, 2016, Daniel B=C3=BCnzli = wrote: > Le vendredi, 22 juillet 2016 =C3=A0 23:46, Spiros Eliopoulos a =C3=A9crit= : > > Angstrom's targeting the use case of network protocols and serialization > formats, a use case where line/column numbers are of dubious value, > > Well when you are dealing with large malformed json streams it's nice to > know where they error=E2=80=A6 But if you target binary data only a byte = count > should suffice. > > > From what I understand, this would require users to modify input rather > than putting any correction logic into the parser itself. > > No the parser itself is in charge of performing this. A very simple > example of this is when you get an UTF-8 decode error. You want to be able > to report the error and let the client restart the decode which is easy to > do by finding a synchronization byte in the input. But again this may not > be useful for binary protocols, it is however useful for decoding text and > parsing languages. > > > Doing that would seem to muddle application and library performance > measurements within the benchmark. Arguably, constructing a generic > in-memory representation is doing the same in essence. > > Not really, it can completely change the outcome of your benchmarks. For > example jsonm allows you to completely eschew going through a generic > in-memory representation before being able to extract the data. > > Best, > > Daniel > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs --94eb2c069db08c2cab053847d779 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable it seems like such a pedantic critique=C2=A0would be most productively pres= ented=C2=A0off the main band, no?

congrats = on the release! exciting to see something like this in the ocaml world. i l= ook forward to its continued improvement.=C2=A0

co= le

On Friday, July 22, 2016, Daniel B=C3=BCnzli <daniel.buenzli@erratique.ch> wrote:
Le vendredi, 22 juillet 2016 =C3=A0 23:46,= Spiros Eliopoulos a =C3=A9crit :
> Angstrom's targeting the use case of network protocols and seriali= zation formats, a use case where line/column numbers are of dubious value,<= br>
Well when you are dealing with large malformed json streams it's nice t= o know where they error=E2=80=A6 But if you target binary data only a byte = count should suffice.

> From what I understand, this would require users to modify input rathe= r than putting any correction logic into the parser itself.

No the parser itself is in charge of performing this. A very simple example= of this is when you get an UTF-8 decode error. You want to be able to repo= rt the error and let the client restart the decode which is easy to do by f= inding a synchronization byte in the input. But again this may not be usefu= l for binary protocols, it is however useful for decoding text and parsing = languages.

> Doing that would seem to muddle application and library performance me= asurements within the benchmark. Arguably, constructing a generic in-memory= representation is doing the same in essence.

Not really, it can completely change the outcome of your benchmarks. For ex= ample jsonm allows you to completely eschew going through a generic in-memo= ry representation before being able to extract the data.

Best,

Daniel

--
Caml-list mailing list.=C2=A0 Subscription management and archives:
ht= tps://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
--94eb2c069db08c2cab053847d779--