Translating a C++ parser to Haskell

The C++ code here is exactly the kind of thing that game developers complain about when they say C++ encourages inefficiency. Calling Haskell fast because it merely draws with that doesn&#x27;t really make sense in this context. Yes, it&#x27;s as fast as C++ code that doesn&#x27;t care in the slightest about efficiency, but people use C++ for the times when they <i>do</i>.<p>E: As some quick examples, peeking an istream in a loop is extremely inefficient[1], yet is done pervasively. The Derivation type has a bunch of separately allocated strings, and a lot of types like std::map&lt;string, DerivationOutput&gt; are pointer filled. To check whether a string starts with &quot;r:&quot;, they allocate a _new string_ and compare it, rather than just doing a normal string comparison.<p>[1] <a href="https:&#x2F;&#x2F;godbolt.org&#x2F;g&#x2F;27o9od" rel="nofollow">https:&#x2F;&#x2F;godbolt.org&#x2F;g&#x2F;27o9od</a>

Nice article, just one small pedantic remark.<p>&gt; Note that Haskell type synonyms reverse the order of the types compared to C++.<p>This is true in the context of the article when compared with the presented <i>typedef</i> definitions, however the modern way to do type synonyms in C++ is via <i>using declarations</i>, which are very similar to the Haskell ones.<p><pre><code> using Path = string; using PathSet = set&lt;Path&gt;;</code></pre>

Attoparsec is fast, but used to have bad error messages.<p>How do the 2 parsers compare w.r.t error messaging?<p>Haskell has Parsec&#x2F;Megaparsec which have better error messages, but are extremely slow.

Note to the author, I found this post extremely hard to read on mobile. I had to scroll horizontally as the text wouldn&#x27;t all fit on screen, and zooming seemed broken. When attempting to zoom or horizontally scroll it would sometimes randomly click some invisible popout that would take me to another page.