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.
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.