<div dir="ltr"><div dir="ltr">On Mon, Apr 1, 2019 at 2:16 AM Stephen J. Turnbull <<a href="mailto:turnbull.stephen.fw@u.tsukuba.ac.jp">turnbull.stephen.fw@u.tsukuba.ac.jp</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In principle, no, one just needs to explain why this battery fits most<br>
of the toys encountered in practice.  That's good enough, and if<br>
during discussion somebody shows another one is better on a lot of<br>
fronts, sure, do that instead. </blockquote><div><br></div><div>OK, I'll acknowledge my comment might have overstated the bar to overcome.  A parser added to the standard library doesn't need to be perfect for everyone.  But adding to stdlib *does* provide a kind of endorsement of the right default way to go about things.</div><div><br></div><div>Among the popular third party libraries, we have several very different attitudes towards designing grammars.  On the one hand, there are formal differences in the power of different grammars—some are LL, some LR, some LALR, some Early.  Also, some libraries separate parser from lexer while others are scannerless.</div><div><br></div><div>But most of these can all parse the simple cases fine, so that's good for the 90% coverage.  However, cross-cutting that formal power issue, there are two main programming styles used by different libraries.  Some libraries use BNF definitions of a grammar as another mini-language inside Python.  Exactly where those BNF definitions live varies, but using them is largely similar (i.e. are they in a separate file, in docstrings, contents of variables, etc).  And sure, EBNF vs. BNF proper.  But other libraries instead use Python functions or classes to define the productions, where each class/function is effectively one term of the grammar.  Typically this latter style allows triggering events as soon as some production is encountered—the event could be "accumulate a counter", or "write an output string", or "perform a computation", or other things.</div><div><br></div><div>There are lots of good arguments for why to use different libraries along the axes I mention, on all sides.  What is not possible is to reconcile the very different decisions into a common denominator.  Something in the standard library would have to be partisan in selecting one particular approach as the "official" one.</div><div><br></div></div>-- <br><div dir="ltr" class="gmail_signature">Keeping medicines from the bloodstreams of the sick; food <br>from the bellies of the hungry; books from the hands of the <br>uneducated; technology from the underdeveloped; and putting <br>advocates of freedom in prisons.  Intellectual property is<br>to the 21st century what the slave trade was to the 16th.<br></div></div>