Comment by pjscott | Hacker News Reader

Comment by pjscott | Hacker News Reader

Parent Full thread

The place where I've seen Haskell really shine is parsing. Parsers are remarkably easy to write in Haskell, thanks to Parsec and its various spinoff libraries. For example, here's a minimal HTTP request parser that Bryan O'Sullivan wrote by essentially translating part of the RFC into Haskell:

https://bitbucket.org/bos/attoparsec/src/tip/examples/RFC261...

It's 54 lines long, pretty trivial, and here's a really cool part: it parses incrementally on strict bytestrings, so you can just do raw socket recv calls and pass the chunks of input to the parser. Similarly, I wrote a parser for the subset of YAML that beanstalkd uses (as part of the hbeanstalk client library), and it was just 11 lines of code. It's very impressive.

(The concurrency and parallelism stuff is also notably slick, but I haven't had as much occasion to use it. Haskell's aversion to side-effects really pays off sometimes.)

By the way, you're right about the Haskell community being friendly and welcoming -- as you yourself demonstrate. :-)

The HTTP request parser doesn't look readable or trivial to me at all.

I'm not familiar with Haskell, so to me the code looks like a mix of high-level declarative and low-level specialized constructs (e.g. skipWhile, takeWhile) interleaved with syntax noise. And it seems to be using quite a lot of external libraries. Also, correspondence of the code with the HTTP spec is completely non-obvious.

In contrast, here's an HTTP response parser I wrote in OCaml using just one library: https://github.com/alavrik/piqi/blob/master/piqi-tools/piqi_... (see lines 26 - 218).

I've just noticed that the code you are referring to is an example. Well, looking at the example, I can hardly come to a conclusion that Haskell shines for parsing.

If you don't know Haskell, and you've never used attoparsec, then I'm not surprised that you don't find that code to be particularly clear or readable. Haskell has a steep learning curve, as I said earlier. This is not a very damning criticism of Haskell's suitability for writing parsing code.

By the way, that long import list is actually just importing some basic stuff from the standard library, and the attoparsec parsing library. One of the persistent minor annoyances of Haskell is writing long lists of module imports.

Fair enough. I didn't mean to criticize Haskell. In fact, I'm planning to learn it.

I was just surprised that this code was presented as a good example of Haskell's fit to the parsers domain. It would be interesting to see if my perception of this code changes once I get more familiar with the language.

Ah, okay, I misunderstood you. Yes, I think your perception of the code will change. In particular, the operators from Control.Applicative (the ones that look especially like line noise) are critical to making heads or tails of it. When I posted that link, I momentarily forgot that they're not obvious. They make sense after you've used them for a little while, though.

I write a lot of ocaml code (for money, even!) and haven't touched haskell for about four years. I still find the haskell version here easier to read. I imagine what's tripping you up is the operator soup. Whilst ugly (one of the things that turned me off haskell) it is a lot easier to read once you are familiar with basic haskell typeclasses (applicative, functor etc). That said, the ocaml version could definitely be a lot nicer. Check out eg

Yojson (search for 'let positive_int') http://forge.ocamlcore.org/scm/browser.php?group_id=153

Mirage (using MPL for zero copy parsing) https://github.com/avsm/mirage/blob/master/lib/net/direct/mp...

Hi there! I do quite a bit of both OCaml and Erlang.

In fact, I borrowed Yojson's json parser for my project (piqi.org). Also, I'm familiar with MPL. It looks very nice, but from what I heard it is fairly immature. And you definitely can't parse HTTP this way :)

I get the impression that the Haskell code was meant to be a direct transliteration of the spec, or had some other artificial restriction on the amount of abstraction. Code for "0 or more of any character" is repeated at least 3 times, as with the use of applicative functor operators to ignore separators (a lot of what looks like syntax noise). Things like numbers (takeWhile isDigit_w8) aren't abstracted, either. There's no real reason that these couldn't be abstracted away. Also, some of the verbosity (and most of the imports) come from using Strict 8bit ByteStrings instead of a type with more built-in abstractions. That said, I don't think you can be blamed for your impression.

It depends on what you compare to. Bryan aimed for speed got to 56% of the speed of the C parser he used as a benchmark, using 54 lines of code. The C parser is a 1,672 lines hand-rolled parser that's only does HTTP, while attoparsec is a general purpose library. Bryan wrote about it here: http://www.serpentine.com/blog/2010/03/03/whats-in-a-parser-...

That's definitely an interesting perspective! Thanks for pointing it out.

Reply on news.ycombinator.com