<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Don't Panic! Better, Fewer, Syntax Errors for LR Parsers · HackerPapers discussions</title><link>https://hackerpaper.kaipfister.de/p/1804.07133/</link><description>Collected HN comments and submissions linking this paper.</description><language>en</language><lastBuildDate>Mon, 02 Nov 2026 11:16:22 GMT</lastBuildDate><atom:link href="https://hackerpaper.kaipfister.de/p/1804.07133/feed.xml" rel="self" type="application/rss+xml" /><item><title>Don't Panic! Better, Fewer, Syntax Errors for LR Parsers — mentioned by bollu</title><link>https://news.ycombinator.com/item?id=23851274</link><guid isPermaLink="false">urn:hackerpapers:mention:1804.07133:23851274</guid><pubDate>Wed, 15 Jul 2020 20:30:19 GMT</pubDate><description>&lt;p&gt;Awesome. I love good research into parsing, since parsing is famously &amp;quot;the solved problem that isn&amp;#x27;t&amp;quot;: https://tratt.net/laurie/blog/entries/parsing_the_solved_pro... I hope to study this paper well (which is by the author of the above post) and understand what their algorithm is. I feel that good error messages make or break a language. Here is the arxiv link of the same paper: https://arxiv.org/pdf/1804.07133.pdf&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/1804.07133/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.PL</category></item><item><title>Don't Panic! Better, Fewer, Syntax Errors for LR Parsers — mentioned by ltratt</title><link>https://news.ycombinator.com/item?id=21788875</link><guid isPermaLink="false">urn:hackerpapers:mention:1804.07133:21788875</guid><pubDate>Sat, 14 Dec 2019 10:59:21 GMT</pubDate><description>&lt;p&gt;I completely agree: the poor quality of error reporting in parsing tools is a significant reason not to use them. When I started looking into this a couple of years back, what surprised me is how much work there&amp;#x27;s been in this spread over decades. Building upon that (and obvious bias alert!) led us to come up with a couple of new algorithms. The current paper draft is https://arxiv.org/abs/1804.07133 (a future version of that paper will probably chop out MF which, in retrospect, adds too much complexity over CPCT+ for the relatively small gains). The Rust library…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/1804.07133/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.PL</category></item><item><title>Don't Panic! Better, Fewer, Syntax Errors for LR Parsers — mentioned by ltratt</title><link>https://news.ycombinator.com/item?id=19336020</link><guid isPermaLink="false">urn:hackerpapers:mention:1804.07133:19336020</guid><pubDate>Fri, 08 Mar 2019 08:34:23 GMT</pubDate><description>&lt;p&gt;&amp;gt; They correctly point out that error handling is by far the biggest one, and usually ends up being the biggest part of a parser for a language, full of crufts and strange mixtures of semantics and syntax. Add to this that you frequently want to try to partially recover -- make a guess as to what was intended and continue parsing in the hopes of finding more actionable errors later in the code. I agree. Personally, I ignored automated error handling in parsing for years because it seemed to be a lost cause. Eventually, I decided to look in more detail at it, and soon came across a rich vein…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/1804.07133/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.PL</category></item><item><title>Don't Panic! Better, Fewer, Syntax Errors for LR Parsers — mentioned by ltratt</title><link>https://news.ycombinator.com/item?id=18405657</link><guid isPermaLink="false">urn:hackerpapers:mention:1804.07133:18405657</guid><pubDate>Thu, 08 Nov 2018 11:51:30 GMT</pubDate><description>&lt;p&gt;&amp;gt; The problem with yacc/bison-style LALR parser generators is that you end up with an LALR parser. Which works great on syntactically correct code, but trying to get a reasonable error message out of one is about as much fun as repeatedly poking yourself in the eye with a sharp stick. The standard ways of getting error messages from LR parsers are pretty bad, but there is a long line of work that&amp;#x27;s tried to make it better. If you&amp;#x27;ll forgive the immodesty on my part, I&amp;#x27;ve been working on updating and fixing that work. There&amp;#x27;s a draft paper at https://arxiv.org/abs/1804.07133 and a beta-ish…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/1804.07133/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.PL</category></item></channel></rss>
