I really appreciate the detailed response!

> Fortunately, there are several better-designed alternatives

Do those you mention handle content type and encodings correctly?

> Have you tried the `xml` package [1]?

Yeah, it doesn't do selection based on CSS selectors or XPath expressions. I don't want to have to manually write tree-traversal code when those already exist.

Take a look at my current scraping code [1] if you want to see how I use HXT. (Just promise not to laugh at my novice work.) Basically, the arrow syntax gives you a weird portal into a different world where you select stuff from a tree using a predicate syntax. I say weird because within the proc and the "-<" arrows, it seems you can only deal with XmlTree operations.

> Funny, I personally think blaze-html is terrific.

It's a bit much, but not awful for generating XML programmatically. The main problem is the need to use "toValue" and "toHtml" all the time. I guess I don't understand why the element building functions don't accept strings.

But for templating, I just don't like embedding templates in the actual source code of the HTTP verb it's for. The main controller code should be about preparing data for the UI, and the UI should be separate from the controller code. You could put it in a separate file and function and import it, of course, but it's still Haskell code, which must be compiled along with the entire app, which slows down the development cycle a lot.

I haven't looked closely at the various web frameworks to see if they support Rails-style reloading (ie., recompiling and reloading the app on each page load). Do you know?

> If you want something like HAML, check out `hamlet`

Hamlet is like someone looked at HAML and didn't grasp why it's so good, because they decided they had to make it look like HTML. Here is HAML:

div#foo
ul.list
- items.each do |item|
li= item.title

And the same in Hamlet:

<div #foo>
<ul .list>
$forall item <- items
<li>#{itemTitle item}

Why invent something that looks like HTML but isn't? HAML syntax is basically (almost) CSS selectors, that's the whole point.

And again, it's apparently meant to be placed inline.

The Snap guys (I think) also invented their own versions of SASS, called Cassius and Lucius. Cassius corresponds to the indented SASS syntax, and uses CSS selectors, unlike Hamlet.

> Frequently having to use `liftIO` ...

Oh, interesting. I don't know about MonadIO yet. Will definitely read up on this.

> My experience has been that the type system plus Haddock docs …

Haddock is great, but a lot of it is non-trivial to understand without having to read the docs very closely. The "xml" library is an example of a simple library where, if you browse around, you can piece together how it works, although it's so bare-bones that if you just want to know how to parse some XML, you have to hunt down the right function, which happens to be in Text.XML.Light.Input; nowhere is there a "how to" introduction which illustrates use cases.

With more complex libraries, the machine-generated docs become increasingly obtuse. For example, I would never, ever have figured out how to use HXT with Hackage alone. I mean, look at it! [2] Is the parser in Text.XML.HXT.Arrow.ParserInterface? Nope. In Text.XML.HXT.Arrow.ReadDocument? Curiously, no. The function to parse a document, runX, is apparently not even in the Hackage database. And good look finding out that this is the function you need to use, never mind the semantics of XML arrows.

[1] https://github.com/alexstaubo/pfinn/blob/master/Scraping.hs

[2] http://hackage.haskell.org/package/hxt