TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Don't worry, your Parser is a functor

40 pointsby ubavicover 1 year ago

4 comments

bruce343434over 1 year ago
I don't mean to be anti-intellectual. But as someone who doesn't know much Haskell and likes to hand roll a precedence climber, my reaction to this is "so what?". But really, what are the implications of this? What does this mean for the code that does the actual parsing, how does this transform how you specify the rules of the grammar in code?
评论 #37739652 未加载
评论 #37738792 未加载
评论 #37738833 未加载
评论 #37738820 未加载
评论 #37739537 未加载
评论 #37738842 未加载
评论 #37738804 未加载
KineticLensmanover 1 year ago
This might not help much with practical compiler writing, but there are some great math-y games here as well: <a href="https:&#x2F;&#x2F;ubavic.rs&#x2F;snake&#x2F;snake.html" rel="nofollow noreferrer">https:&#x2F;&#x2F;ubavic.rs&#x2F;snake&#x2F;snake.html</a>
amlutoover 1 year ago
For those of us who don’t stare at parsers on a regular basis, this seems odd to me:<p><pre><code> newtype Parser a = P (String -&gt; Maybe (String, a)) </code></pre> So, on a successful parse, it returns the result and the rest of the string. That’s seems error prone and rather weak. What ensures that the “rest of the string” is, in fact, a suffix of the input? I assume the purpose of this design is for compatibility with lazy input sequences, where the “rest of the string” could still be lazy. But surely some Haskell type magic could ensure that the supposed lazy suffix is actually a suffix.<p>If I were writing a serious parser intended for human use with nice error messages, I would want to know the <i>position and length</i> of the parsed output, which I could infer from actual strings with known length, but which I may not be able to efficiently infer from lazy sequences.<p>So I’m confused. Why is this a good design?
评论 #37741051 未加载
评论 #37742592 未加载
评论 #37742614 未加载
评论 #37743836 未加载
评论 #37740863 未加载
alexvitkovover 1 year ago
No, a parser is not an functor, an applicative or god forbid a monad.<p>The ratio of the effort academics spend thinking formally about parsers relatively to how often you need to write a parser is probably 50:1. Not as bad as sorting algorithms, where they take up 50% of a CS curriculum, but still pretty bad.<p>A parser reads an array of tokens and spits out a tree. You can write one for any relatively sane grammar by hand in two hours if you need to, infix operators &amp; precedence rules included, with the added benefits of decent performance, the ability to have good errors and the peace of mind that you&#x27;re not confined by what can be neatly expressed by parser combinators.
评论 #37743200 未加载
评论 #37738581 未加载
评论 #37738715 未加载
评论 #37738799 未加载
评论 #37738829 未加载
评论 #37738713 未加载
评论 #37738425 未加载
评论 #37739049 未加载
评论 #37739265 未加载