The only thing I feel to recommend given the generality of the question is to say: Pick some concrete instances of Functor, and play with them. Write a program with a failing component using 'Maybe' then see how much you can get done without pattern matching. Write a program over some lists and use fmap instead of map. Realise there isn't much more to fmap than a very general signature and some laws. See what the laws mean for the two concrete instances that you just used. Be satisfied. When you get a little further on your journey and see more interesting examples of the class you will see how useful it is. For instance most parser interfaces admit a functor instance. Which means that say you had a language with variable identifiers with a leading '$' sign followed by a string, writing a parser is super simple. Assume 'stringVar' is a 'Parser String' that parsers an identifier and 'Var' is a new type on strings for wrapping identifiers then Var `fmap` stringVar is a 'Parser Var'. I could offer again that a functor is nothing more than a principled way to change the 'generic type' of things that look like containers of type Foo<T>, not sure if that is helpful, given your previous reading list. I hope this offers some insight. Haskell, like any learning endeavour requires you to just mess about with it until things start to click. You will miss out on a very rich learning experience if you cast it aside. Good luck!

As the name implies, the concept of an applicative functor builds on the concept of a functor, so it will help to start with a thorough understanding of functors. A functor allows you to lift a function of Foo -> Bar into some context of Foo, so that when the expression is finally evaluated you will end up with a value of Bar in that context. An applicative functor allows you to lift a function of an arbitrary number of parameters, such as Foo -> Bar -> Baz, into that number of values (of those types) already in contexts. So the example function could be applied to a context of Foo and a context of Bar, and would ultimately evaluate to a context of Baz. e On Sunday, October 19, 2014, Frank wrote:

Thanks but I think this misses the point a bit. A some point in time, I will need an explanation about applicatives and teg supposedly best documentation (or at least the documentation I see advocated in numerous places) seems really bad at providing that explanation, a point I find worrisome. I know myself well enough to say becoming comfortable with functors will not make understanding applicatives any easier if the applicatives explanation is not clear and, right now, the explanation is not clear.

On Sunday, October 19, 2014, Karl Voelker javascript:_e(%7B%7D,'cvml','karl@karlv.net');> wrote:

...

I suggest that you ignore applicatives for now and just focus on plain-old functors. They are the simplest part, and once you are confident in dealing with them, adding on applicatives will be much easier.

And, although it can be difficult when you are really lost, if you can ask some more specific questions, this list will provide plenty of answers.

-Karl

...

On Oct 18, 2014, at 3:37 PM, Frank wrote:

I've had a go at LYAH and CIS 194 and the Typeclassopedia and I just don't get get functors and applicatives. I'm simply not understanding them, what the various symbols/keywords mean, what they represent, how to think of them, etc. Nothing. Is there any kind of documented model I should be considering? Is there a "functors and applicatives for Dummies" I should read? Should I just give it up, not bother with Haskell and just stick to scheme/ruby/C++?

-- P.S.: I prefer to be reached on BitMessage at BM-2D8txNiU7b84d2tgqvJQdgBog6A69oDAx6 _______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

---

Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

-- P.S.: I prefer to be reached on BitMessage at BM-2D8txNiU7b84d2tgqvJQdgBog6A69oDAx6