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