- Designing a typeclass
 - Folding over sum types
 - Desire for a generalized 
fmap - The 
lenslibrary - The 
SuccessandFailureprisms - The 
Either-Validationisomorphism - The 
Validateclass - Exercises
- Exercise 1
 - Exercise 2
 
 
In this course we have emphasized two contrasts:
Rightis the side ofEitherthat functions likefmapand(>>=)act upon;Leftis the side that just tags along for the ride.Eitheris the type for which(<*>)stops at the first left value;Validationis the type for which(<*>)accumulates left values.
In this final lesson of the course, we will set aside these differences, ignore the functions and typeclass instances, and focus on the similarities in the structure of the data:
Beyond the choice of which side we call “left” and “right”,
Either a bis not really different fromEither b a.Although
EitherandValidationhave different names for their constructors, the two types have exactly the same structure.
From this perspective, Left/Right and Either/Validation differ superficially – in name only. We can exploit these symmetries to design with fewer, more generally-reusable components.
Worrying about generalization too soon can be dangerous. Whether you’re writing your own code or trying to understand someone else’s, we recommend following the approach we have taken here in this course: don’t start with a generality. Start with concrete examples, then observe what aspects they share. As a learner, this order provides more opportunity to understand complex or abstract concepts by grounding them in concrete ones. As an author, this order helps ensure that your more abstract inventions make sense and have purpose.

