Re: [Caml-list] ANN: angstrom

[Spiros Eliopoulos <seliopou@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3205 bytes --]

On Mon, Jul 25, 2016 at 12:21 PM, Daniel Bünzli <daniel.buenzli@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…

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.

[-- Attachment #2: Type: text/html, Size: 3869 bytes --]