FWIW, this is specifically List#traverse. You might also consider writing traverse for every possible Traversable. Unfortunately, that is a lot of work, since there are infinity of them, so as a compromise, perhaps the more common ones; List, Option, Either<T, _>, Tuple2<A, _>

@tonymorris Oops...i totally did not see that. I agree that it's a list traverse.
I was planning to wtite it for every traversable, but as u said its a lot of work. That's why decided this specific one...because i found myself writing this a couple of times. I will update the PR.
Thanks.

Yeah no worries. You'll probably want the others some day too!

@tonymorris sure thing 👍

@tonymorris and @amarpotghan
For some reason I thought traverse was defined on Monad with the signature:
traverse:: Monad f => List a -> (a -> m b ) -> m (t b)
whereas it is actually on Traversable:
traverse :: Applicative f => (a -> f b) -> t a -> f (t b)

Given the use of different applicatives, is the best way to handle this to represent the function on a traversable type t as:
public <B> ${Applicative}<${Traversable}<B>> traverse${Applicative}(F<A, ${Applicative}<B>>)
so for this example by @amarpotghan for traversing lists we would have on class List:
public <B> Option<List<B>> traverseOption(F<A, Option<B>)

Some other classes this would apply to that I use: IO(?), SafeIO, Seq, Set(?), Stream, P1, Validation<A, _>, State<S, _>.

This of course is starting to create alot of combinations, but it would be good to agree on the approach and fill in the missing implementations at some future point.

Yep that's the problem. You have NxM instances to write where:

• N = Number of Applicative instances
• M = Number of Traversable instances

Given the limitations of Java's type system against the intractability of this problem, Functional Java has had a history of, "just pick the most common ones that I have the energy to write today."

Consequently, I cannot speak for the energy of @amarpotghan.

For TODO things, we should create Github issues. We can decide what we want to do for traverse here and then create an issue documenting what is left to do.

I had a look at doing this for the Option type last night (so don't worry about Option). BTW, I also had a look at the laws that traversal had to comply with, but only really understood the identity law. I suspect this won't be a barrier to writing the code.

@mperry Thanks. I will not touch Option type.

No problem. FYI, I started reviewing these changes, but have not had time to finish yet. I will try to do some more tonight.

@mperry thanks

I have had enough for now. Will check back tomorrow. Thanks for your hard work, it is much appreciated.

@mperry Thanks for all the observations. I changed the required, please have a look :). In the validation class (without type annotations), couldn't guarantee Intellij support. I hope that works in Intellij 14. My side, I will upgrade soon.

I think we are almost done. Just the hamcrest issue and either javadoc to address.

Still places in the javadoc that mention fail, particularly for Either. Go to the "files changed" tab in this PR and search for "fail". We are almost there...