Revisiting 'Monadic Parsing in Haskell' | Hacker News Reader

Revisiting 'Monadic Parsing in Haskell'

vaibhavsagar.com

116 pointssigna1110 comments

> This was the first application of monads I encountered that actually made my life simpler, and I started to realise that there was more to monads than smugness and being inaccessible to newcomers.

I had the same experience, Parsec is one of the best examples of the power of Haskell and what really sold me on the language.

It's also a great way to communicate the utility and effectiveness for using monads to solve programming problems (in this case as an alternative to messy Regex).

I'm really looking forward to Purescript [1], which has its own Parsec library in development [2] so I can use it with my frontend development... which is typically where I used Regex the most (in the DOM).

[1] http://www.purescript.org/

[2] https://github.com/purescript-contrib/purescript-parsing

I've had a similar experience, where I'm not even a fan of the Haskell ecosystem overall, but Attoparsec is such an astoundingly good library that it makes everything worth it. It's not just a convenience like other libraries would be -- in fact, it comes with the built-in inconvenience of using a language I don't normally use. But it actually gives me the ability to solve problems I would not solve without it. Parsing is the killer app for Haskell.

So far I haven't been satisfied with any Parsec port to another language. This article helped me understand how a lot of the design of [Atto]parsec is just the natural result of using Haskell for what it's good for, and that aspect seems to translate badly when Haskell is replaced with another language. But maybe the Purescript port can do better.

Graham Hutton, one of the authors of the original paper, also wrote a wonderful book "Programming in Haskell". I would wholeheartedly recommend it to both the programming novice and the experienced programmer trying to learn Haskell and monadic programming.

Chapter 13 of (the second edition of) that book also revisits the original paper from a modern viewpoint and overlaps with the current article. For example, both the book and the article mention the similarity with the state transformer, introduce instances of 'functor' and 'applicative' before the 'monad' instance, and discuss the 'alternative' instance.

The rhyme for the altered Parser: A parser for things is a function from strings to potentially a pair of that thing and its string.

At the end they mention the yoctoparsec library which abstracts away the String to a free stream type.

    type Parser b t a = FreeT ((->) t) b a

I'd like to see someone make a rhyme out of that.

A parser just means A function from streams To maybe a pair, One in which there Is the stream, and the thing that it means

You should win a Grammy for that.

Fwiw, we can go even further and define these combinators in terms only of typeclass constraints needed on the return monad, the "finally tagless" or "mtl" style.

https://hackage.haskell.org/package/parsers-0.12.8/docs/Text...

Great article! Also, I was surprised at how short and readable the original paper was. This is a really nice follow up.

I only recently started learning Haskell seriously, and it was surprising to learn that “Applicative” is a more recent discovery.

To be precise, Applicative was known for quite some time by mathematicians as "lax monoidal functor". That this concept is useful for structuring programs is the recent discovery. Even in the last 10 years we've learned a lot about functional programming and I'm sure in the next 10 years we'll learn a lot more that really changes the way we approach it.

Reply on news.ycombinator.com