<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Recent changes to 18: infixNotation() might be made better</title><link>https://sourceforge.net/p/pyparsing/support-requests/18/</link><description>Recent changes to 18: infixNotation() might be made better</description><atom:link href="https://sourceforge.net/p/pyparsing/support-requests/18/feed.rss" rel="self"/><language>en</language><lastBuildDate>Tue, 14 Aug 2018 14:59:53 -0000</lastBuildDate><atom:link href="https://sourceforge.net/p/pyparsing/support-requests/18/feed.rss" rel="self" type="application/rss+xml"/><item><title>#18 infixNotation() might be made better</title><link>https://sourceforge.net/p/pyparsing/support-requests/18/?limit=25#aba4</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;Packrat is already enabled: &lt;a href="https://github.com/mozilla/moz-sql-parser/blob/dev/moz_sql_parser/sql_parser.py#L19" rel="nofollow"&gt;https://github.com/mozilla/moz-sql-parser/blob/dev/moz_sql_parser/sql_parser.py#L19&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;I suspect the number of KNOWN_OPS passed to &lt;code&gt;infixNotation&lt;/code&gt; &lt;a href="https://github.com/mozilla/moz-sql-parser/blob/dev/moz_sql_parser/sql_parser.py#L275" rel="nofollow"&gt;https://github.com/mozilla/moz-sql-parser/blob/dev/moz_sql_parser/sql_parser.py#L275&lt;/a&gt; is too great for the given &lt;code&gt;sys.setrecursionlimit(1500)&lt;/code&gt;.  Increasing the recursion limit solves the problem for simple cases, but real life expressions can quite a bit longer.&lt;/p&gt;
&lt;p&gt;&lt;code&gt;infixNotation&lt;/code&gt; is a piece of elgant code, but creates a parser that runs in &lt;code&gt;O(2^n)&lt;/code&gt; where &lt;code&gt;n&lt;/code&gt; is the number of parsed operators. This  can get out of hand quite fast, and the recursion limit is actually protecting the parser from trying too hard on pathelogical input.&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Kyle Lahnakoski</dc:creator><pubDate>Tue, 14 Aug 2018 14:59:53 -0000</pubDate><guid>https://sourceforge.netb6bd7ed6869008440c0a02981ec8a7b4244f6f86</guid></item><item><title>#18 infixNotation() might be made better</title><link>https://sourceforge.net/p/pyparsing/support-requests/18/?limit=25#1c31</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;If you have a sub-expression that is being repeatedly matched, try enabling packrat parsing: &lt;a href="https://pythonhosted.org/pyparsing/pyparsing.ParserElement-class.html#enablePackrat" rel="nofollow"&gt;https://pythonhosted.org/pyparsing/pyparsing.ParserElement-class.html#enablePackrat&lt;/a&gt;&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Paul McGuire</dc:creator><pubDate>Fri, 03 Aug 2018 03:32:50 -0000</pubDate><guid>https://sourceforge.net9554d3c36e7aa8b367f52c1f31819ca3f2f187f0</guid></item><item><title>infixNotation() might be made better</title><link>https://sourceforge.net/p/pyparsing/support-requests/18/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;I am going through the match attempts for my parser &lt;a class="" href="https://github.com/mozilla/moz-sql-parser" rel="nofollow"&gt;moz-ssql-parser&lt;/a&gt; while parsing&lt;/p&gt;
&lt;p&gt;&lt;code&gt;select * from task where build.product is not null and build.product!='firefox'&lt;/code&gt;&lt;/p&gt;
&lt;p&gt;The parser does a lot of trackback as it tries to match the WHERE clause; much more than it should.  Please change &lt;code&gt;infixNotation()&lt;/code&gt; to take advantage of the fact that clusters of infix binary operators always begin with an operand, alternate operator and operand, and end with an operand:&lt;/p&gt;
&lt;p&gt;&lt;code&gt;[build.product] is [not null] and [build.product] != ['firefox']&lt;/code&gt;&lt;/p&gt;
&lt;p&gt;(you may notice my grammer did not include &lt;code&gt;not&lt;/code&gt; as a unary operator to &lt;code&gt;infixNotation()&lt;/code&gt;)&lt;/p&gt;
&lt;p&gt;By matching this alternating pattern the matching process can go much faster.  Precedence is handled with some post processing to orangize this into a tree.  Of course, the difficultly will be splitting up a single &lt;code&gt;infixNotation()&lt;/code&gt; call, infected with unary and trinary operators, into a hierarchy of &lt;code&gt;infixNotation()&lt;/code&gt; calls containing only binary operators.&lt;/p&gt;
&lt;p&gt;Thank you&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Kyle Lahnakoski</dc:creator><pubDate>Thu, 02 Aug 2018 13:54:06 -0000</pubDate><guid>https://sourceforge.netb314f7016e111f854e1826d0ae350b4e66edde7a</guid></item></channel></rss>