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ünzli <daniel.buenzli@erratique.ch> wrote:

> Le vendredi, 22 juillet 2016 à 23:46, Spiros Eliopoulos a écrit :
> > 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… 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