I would say that Snap is more like Pyramid and Happstack... not quite like anything else. Snap has snaplets, Pyramid has components.

Happstack on the other hand ... invented type-safe routing, which I haven't seen anywhere else before it. Dynamic languages tend to have something vaguely similar you might call "named routes" but they don't provide the same static guarantees.

Happstack likes to use templates mixed in with code, which sounds insane but note that this is rather different from code mixed in with templates. This templating is type-safe and syntactically checked at compile time, and allows reusing all of Haskell rather than a limited subset, so using modules and functions these templates easily end up more modular and composable than any template language you've ever seen before. Admittedly, it's not the most designer-friendly solution (but should designers really mess with the HTML to begin with?).

Happstack likes to use a persistence system for native Haskell values. I suppose you could say this is similar to ZODB with Pyramid, although it's "on steroids" (due to Haskell).

I'm biased towards Happstack as you might notice from this post, but the point I'm trying to make is more that Happstack is non-traditional (in the tradition of Haskell!) and not quite like anything else. This is often seen as a weakness because it means it is less familiar to new users; I might wonder why they're using Haskell to begin with, then. :-)

(You could even argue that Happstack should be more familiar, to Haskell programmers, because it favors reuse of existing Haskell idioms like combinators, algebraic data types, monad transformer stacks...)

That said, if you do want a more traditional framework, Snap and Yesod are both great options.

Believe it or not, Happstack is the one I favor and use, for basically all of these reasons (though I am far too much of a RDBMS partisan to use acid-state).