I try to address a relative lack of entry-level material on composing functions targeted for FP newcomers. While the usage and benefit of data types like Option or List are quickly grasped, there is less focus on how to create and compose functions operating in the context of these types. While the following are general for FP, frameworks in focus are functionaljava for Java, and Scalaz for Scala.

#### Lifting functions to operate in a context

This article is pretty in medias res, holes would be filled in in later parts, but don’t be afraid to comment or ~~google~~ duckduckgo if encountering anything unexplained. A function from a value of type A to a value of type B can be denoted `A => B`

, or in case of functionaljava `F[A, B]`

(please forgive using Scala’s square brackets instead the Java standard less/greater-than sign for type parameters, but it less pain when writing HTML code). Now assume we have a function `f1: A => B`

, and also a value `v1: Option[A]`

. It is evident that since Option is a Functor, we can map `f1`

on `v1`

to get a new value `v2`

of type `Option[B]`

. The code is something like `v2: Option[B] = v1.map(f1)`

.

But we hear all the time that FP makes function composition easy. Now if we have a function `f0: X => Option[A]`

, can we compose it with our `f1`

to get a function `fc: X => Option[B]`

? Since the types of the output of `f0`

and the input of `f1`

don’t match, a newcomer might begin writing an (anonymous) function taking an optional value and applying map on it with the function (I actually saw this). Instead we can just lift any function to operate in a given Functor context. How? Since Java doesn’t support typeclasses, there are different methods on the `F[A, B]`

class to perform the lifting. To get a function `Option[A] => Option[B]`

from our `f1: A => B`

, we would call `f1.mapOption()`

. There are similiarly named methods for various functors, like `mapList`

, `mapSuccess`

or `mapFail`

(the latter two lifting the function to operate on the success or failure side of a Validation, respectively). So to compose, we would just write `fc = f0.andThen(f1.mapOption())`

instead of the boilerplate with extra wrapper functions. With Scalaz 6, we can use the polymorphic `f1.lift[Option]`

method for lifting, and for any Functor, not just Option.

#### Lifting the return type of a function

We might get into a situation where we have a function `A => B`

but would need `A => F[B]`

. If F is Pure (or Pointed, the latter is the new name of Pure in Scalaz 7), then this should be possible (note that if F is a Monad then it is Pure by definintion). Just “should” since again, Java has no typeclass support, so we have to rely on the specific method being available on `F[A, B]`

, for example `optionK`

for promoting to `F[A, Option[B]]`

. Just look for methods ending with K, which refers to the Kleisli operation. Indeed, in Scalaz 6 we can use `f.kleisli[Option]`

instead.

#### Lifting a value

While we are here it is worth mentioning that if F is Pure then we should have a way of producing `F[A]`

from a value of type `A`

. For functionaljava there are various static methods on the data structures, like `Option.some`

, `List.list`

or `Validation.success`

. For Scalaz 6 we can use the `a.pure[F]`

way.

#### Parting words

Instead of writing a custom wrapper lambda for a specific function, rather lift that function into the context using the appropriate method if there is one. If isn’t (in case of functionaljava) then at least write the lifting method as a general static helper method, or better consider adding it to fj and sending a pull request. In Scala a lambda is more lightweight syntactically than in Java, so in Scala wrapping using a lambda is more common I assume (no hard evidence), but following or at least knowing the FP way can ease our life if eventually refactoring the function to be polymorhic in the Functor type is needed. Have fun coding!