[thosakwe]

I learned Haskell this year.

After reading this article, the conclusion I drew was, "Cool, so I can `fmap` over my parser now and transform what I parse using functions."

To answer your other questions: I'm not sure it means much for the code that does the actual parsing, nor how you specify the grammar's rules, it's more about being able to transform the output using functions.

If your static analyzer is a function, you could now write `fmap staticAnalyzer myParser`.

[Joker_vD]

> about being able to transform the output using functions.

Can't one always use functions to transform other functions' outputs?

> If your static analyzer is a function, you could now write `fmap staticAnalyzer myParser`.

rolls eyes

    def compile(text):
        ast = parse(text)
        ir, symtable = static_analyze(ast)
        asm = lower(ir, symtable)
        return assemble(asm)

Ability to write that in the point-free style is really not that important, IMHO.

[thosakwe]

Yes, but if it we're talking about parser monads, then usually you can't apply a function directly to a parser's result without either:

1. Being within the same monad. For example, you can `bind` a `Parser a` to a function only if it returns `Parser b`.

2. Performing an actual action and breaking it out of its monad.

For example, if you're using the Parsec library, and you have a `Parser Int`, you can't get to that int without using a function like `parse`, performs the actual action of parsing input text.

With a functor, you can compose a `Parser a` within an `a -> b` function, instead of having to return `Parser b` in your function.

So if you have a `Parser Int`, and you want to turn it into a parser that multiplies its parsed input by 2, you can write `fmap (*2) myParser`, instead of having to write `myParser >>= \a -> return (a * 2)`.

Parsers being functors means it's easier to compose them with other things, without having to actually perform the parse until you need to.