The battle of the decouplers.

Photo by Robert Linder on Unsplash

Pre-Intro

Hi, this article is the first of a series showing the same domain problem being modelled with different techniques, I will link the following articles here as they get published:

• #1 Scenario & Transformers (you are here)
• #2 Free (TBC)
• #3 Freer (TBC)
• #4 Tagless Final (TBC)

Intro

Hello, I’ve been wanting to make a post about these Haskell techniques for modelling domain logic and decoupling it from implementation for a while.

This was mostly motivated by the fact that I really like the three (Free, Freer, Tagless Final), but never found an article showing them used side by side, in comparison to a Transformers based implementation. I will try to highlight the pros and cons of each approach, and hopefully by the end you will be able to use whichever technique you deem fit for fun and profit.

So without much further ado let’s jump straight into it.

The Domain

A thread that connects the three techniques is their purpose. All three are useful techniques for modelling the domain of our problem while abstracting (to be read as omitting) the implementation. Let us take a hypothetical domain and exemplify what we mean by this; so let us write a quick scenario:

The Scenario

Let us imagine we were tasked to implement a very basic calculator. Management together with the design team names this project BCalc (sometimes referred to as BC because it is incredibly catchy). Being super innovative BCalc allows us to:

1. Add an Int to our result previous result;

1. Subtract an Int from our result;

1. Retrieve our result, print it to screen together with some “wicked” prompt;

Up until now it all makes a lot of sense, but to fully grasp the power of the system we will also append to our above scenario a few more lines, which highlight the flexibility of our approach:

At a (much) later date (and close to the deadline), management, together with the client, decide that they would also like to be able to feed a function to BC, which modifies the last result. They have very, (very), high plans for BCalc — maybe even adding some AI functions to it (mostly because it sounds cool).

The Transformers based implementation

Ok, so you know Haskell, you’ve read about Monad Transformers (not the Transformers franchise), and you realise that you can model BCalc with the use of the StateT monad transformer, on top of IO. So you get to work and produce the following unique and innovative piece of Intellectual Property that will bring you fame and fortune:

import Control.Monad.State

-- The type of our Programs  
type Program a = StateT Int IO ()

-- Adds an Integer to the last result  
adds :: Int -> Program ()  
adds x = modify (x +)

-- Subtracts an Integer to the last result  
subtracts :: Int -> Program ()  
subtracts x = modify $ flip (-) x

-- Prints the result in the best marketed way possible  
printsResult :: Program ()  
printsResult = get >>= \r -> liftIO $ putStrLn ("BC> " <> show r)

-- This is how easy it is to write Programs for BC  
exampleProgram :: Program ()  
exampleProgram = do  
  adds 2  
  adds 3  
  printsResult  
  subtracts 3  
  printsResult

You’ve done it (colleagues admire your cunning). Now you can share with management your Transformer based EDSL, and they can have fun writing many (many, many) programs using your exposed API to your Program monad. Because you are kind, you also surface to them a function that runs BC programs written in your EDSL. In a spur of inspiration you name it runProgram.

-- Run this to experience BC  
runProgram :: Program a -> IO a  
runProgram = flip evalStateT 0

Equipped with runProgram and exampleProgram, every one spends endless hours of fun writing (and nicely printing) computations that they never even imagined. Like so:

λ> runProgram exampleProgram  
BC> 5  
BC> 2

Storms gather when management tell you about the addition of the new feature they’ve decided to add to BC (just as you were finishing your ☕️ break, always …). But you are well equipped with perseverance and patience, and diligently go back to work and produce the following missing utility, unlocking the full potential of BC.

-- Applies a function to last result  
appliesFunction :: (Int -> Int) -> Program ()  
appliesFunction = modify

Now you can rest at ease, as people can extend BC with unfathomed rich functions — as seen in the following example:

-- the answer to the Ultimate Question of Life, the Universe, and Everything.  
applyTheAnswer :: Program ()  
applyTheAnswer = appliesFunction (const 42)

exampleProgram2 :: Program ()  
exampleProgram2 = do  
  adds 2  
  adds 3  
  printsResult  
  subtracts 3  
  printsResult  
  applyTheAnswer   
  printsResult

You can now rest at ease; your colleagues can see why when running:

λ> runProgram exampleProgram2  
BC> 5  
BC> 3  
BC> 42

So?

Okay, so what is “wrong” with the above approach? You’ve ended up with a nice abstraction over BC that allows people to write programs with your provided API, it is easy to extend and you’ve successfully delivered your product. The answer is: “nothing” is fundamentally wrong with this approach, and it is very trivial to work with and implement.

BUT, on the other hand, there are some issue that I would like to mention, and those are:

There is no decoupling between the business logic of BC and its implementation.

In essence there is no way for us to look at a BC program and dump its sequence of instructions. Of course, we could add some more transformers on top to keep track of our instructions, or of what we’ve executed up until a point — but that would not be elegant (and we don’t care for stuff which is not elegant).

Imagine having to take our exampleProgram or exampleProgram2 and rewrite them into an intermediary representation where we do fancy optimisations, fusion, and whatnot — we’ve hit an invisible wall. And that is where the decoupling techniques come in handy.

Every time we added a new feature to BC we got caught up in implementing it.

I can hear you saying it, and you are right. I could have replaced the provided Program () implementation with undefined and kept it abstract, but that’s not really the point. The point is that, now our Program has one way and one way only to interpret commands, and that is their implementation. If further down the line you needed to change the interpretation of what each instruction does, you would have to do it there, in the implementation itself. You wouldn’t be able to easily keep two printsResult implementations in parallel (one for prototyping, and one that shoots lasers), without adding another function printsResultAndShootsLasers.

Summary

So to summarise:

• + easy to do.
• + minimal dependencies.
• + fast — as close to the metal as it gets.
• - inflexible once implemented.
• - does not (elegantly) allow manipulation of the program’s AST.

Conclusion

The article has introduced the series of short articles on modelling domain specific logic in Haskell. It has also introduced a (silly) problem, and proposed a trivial Transformers based solution to it. Lastly, the article has also tried to highlight the shortcomings of such an approach, and made us curious about how to deal with them.

Until the next time, may the λ be with you.

Links

• I originally posted this on medium.

Or at least my attempt at explaining it

-- The use of this will be explained later
> import Control.Monad ((<=<))

A monad is a haskell Class - this means it comes with specific methods. Let’s have a look at what ghci has to say about it.

λ> :i Monad
class Applicative m => Monad (m :: * -> *) where
  (>>=) :: m a -> (a -> m b) -> m b
  (>>) :: m a -> m b -> m b
  return :: a -> m a
  {-# MINIMAL (>>=) #-}
  	-- Defined in ‘GHC.Base’
instance Monad (Either e) -- Defined in ‘Data.Either’
instance Monad [] -- Defined in ‘GHC.Base’
instance Monad Maybe -- Defined in ‘GHC.Base’
instance Monad IO -- Defined in ‘GHC.Base’
instance Monad ((->) r) -- Defined in ‘GHC.Base’
instance Monoid a => Monad ((,) a) -- Defined in ‘GHC.Base’

Ok, so we know it is a subclass of Applicative, we can see it is implemented for all of these data structures and it comes with some funky looking operators, namely:

• (>>=) aka. bind

• (>>) which I like to call “and then”

• return - which is the same as pure from Applicative

I could go on and on about the theoretical foundations of it, but I’d rather focus on a trivial example.

The identity Monad

Let’s define our own Monad from scratch to try to understand how it works - for this I propose the simplest of all lawful monads - the Identity monad. The reason why I call it a monad is because it behaves like one - i.e. the instance of Monad is lawful (don’t get bogged down, yet in terminology - but keep in mind).

> data Identity a = Identity a

As you can see, our Identity data type takes any value and places it inside. It’s so basic that we can guarantee that if we have an Identity a we can always get its content - let’s write a function that does just that:

> getContent :: Identity a -> a
> getContent (Identity x) = x

Mentally we can think of Identity as a Box.

So what can we say about it? Well firstly - we can be sure it has a lawful Functor instance. Given any Box a and a function a - > b we can obtain a Box b:

> instance Functor Identity where
>   fmap f (Identity a)  = Identity $ f a 

Nice. We can also see that given any boxed function Identity (a -> b) and a boxed value Identity a we can get a boxed Identity b value. Furthermore, given any a we can always box it into Identity a. This is an easy win and we get our Applicative instance.

> instance Applicative Identity where
>    (Identity f) <*> (Identity a)  = Identity $ f a
>    pure a = Identity a

Ok, so we’ve done all the footwork up until the Monad instance. Let’s have a closer look at the bind operator (>>=).

  Monad m => (>>=) :: m a -> (a -> m b) -> m b

If we specialise this operator to what we’re trying to achieve it looks more like this:

  (>>=) :: Identity a -> (a -> Identity b) -> Identity b

We have the following, a boxed value a, a function from a to a boxed b, and at the end the result is a boxed b. Mentally, we can think of the second function as something that unboxes the first value, and then returns our new box

• let’s see this in our implementation.

> instance Monad Identity where
>   (>>=) (Identity value) boxingFunction = boxingFunction value

Can you see what we’ve done? We’ve unboxed the value, and passed it to our boxingFunction. Ok, maybe it isn’t very clear - but let’s take a second and have a chat about it. Our data type Identity is useless - in many ways it could disappear from all of our implementations because it doesn’t give us much. We could really push it and say that fundamentally Identity a and a are one and the same thing - only one is wrapped in this mental box and the other isn’t. We could say that our bind is

  (>>=) ::  a -> (a -> something b) -> something b

and if we squint we could almost say that in this instance, Identity doesn’t really give us much more information about anything. We could even say that it’s (&) :: a -> (a -> b) -> b from Data.Function.

In any case - why does this matter - and how is it relevant? Well here’s why it matters - let’s take Maybe as another example. Say we have the function half which returns the half of an even number or Nothing if it is an odd number.

> maybeHalf :: Int -> Maybe Int
> maybeHalf x
>   | even x    = Just $ x `div` 2
>   | otherwise = Nothing

λ> maybeHalf 1
Nothing
λ> maybeHalf 2
Just 1

Squinting again we see something which we’ve already seen. maybeHalf’s type looks vaguely familiar - indeed its type is the same as the second argument of (>>=) namely ` a -> m b or in our case a -> Maybe b, or even more specific Int -> Maybe Int`. That’s great because now we can use the operator:

> maybeQuarter :: Int -> Maybe Int
> maybeQuarter x = maybeHalf x >>= maybeHalf

Ok, so what happened now? Think of (>>=) as taking the result of maybeHalf x and passing it to the function maybeHalf again. That’s neat because, when we see it action, it actually makes a lot of sense.

λ> maybeQuarter 2
Nothing
λ> maybeQuarter 4
Just 1

The do notation

Another cool thing Monads unlock is haskell’s do notation. Let’s refactor the above maybeQuarter to leverage this.

> maybeQuarterDo x = do
>   half    <- maybeHalf x
>   quarter <- maybeHalf half
>   return quarter

The two are one and the same function - but in different notations. Look at the do notation one, and then look at the bind notation one. Some intuition might emerge.

Fundamentally, a Monad is a type class that allows us to take an instance of itself containing a value, and a function from that value to another instance of itself containing possibly a different value. This allows us to easily compose monads. One last example

The fish (<=<)

The fish, is the epitome of what I just said because in the context of a monad it is the moral equivalent of our composition operator (.).

λ> :t (>=>) :: Monad m => (b -> m c) -> (a -> m b) -> a -> m c
λ> :t (.)   ::            (b ->   c) -> (a ->   b) -> a ->   c

You can see it, right? So how could we refactor our maybeQuarter now? Whatabout:

> maybeQuarterFish :: Int -> Maybe Int 
> maybeQuarterFish = maybeHalf <=< maybeHalf

End

That was it. I’m sure it all makes sense now - maybe.

It does this by providing two constructors:

> -- | remember this as it will come in handy later
> import Control.Monad (join)

> -- | Ignore the ' as they are there to not clash with the Prelude Either.
> data Either' e a
>   = Left'  e  -- ^ Left allows us to return an error, or short circuit.
>   | Right' a -- ^ Right allows us to return the result

For example say we were implementing a (safe) function for division - we could do it like this:

> division :: Int -> Int -> Either String Int
> division a b 
>     | b == 0    = Left "Sorry, cannot divide by 0."
>     | otherwise = Right $ a `div` b

Now if we wanted to use the result we could pattern match:

> calculate :: IO ()
> calculate = do
>     let n = 40
>     putStrLn $ "Please enter a number to divide " ++ show n ++  " by: "
>     y <- readLn :: IO Int
>     x <- pure $ division n y
>     case x of
>       Right x' -> print x'
>       Left e   -> print $ "Oh no:" ++ e

A better way to use either

OK so that’s pretty good already. We have managed to create a pure function that takes our sum type, and can handle errors. But Either actually gives us a neat function to tidy up that pattern match into a simpler pattern. I am talking here about either (which is indeed very similar to Maybe’s maybe).

> calculate2 :: IO ()
> calculate2 = do 
>     let n = 40
>     putStrLn $ "Please enter a number to divide " ++ show n ++  " by: "
>     y <- readLn :: IO Int
>     x <- pure $ division n y
>     either leftFn rightFn x
>       where
>         leftFn = print . ("Oh no: " ++)
>         rightFn = print
>
>  -- or inlined it would look like this 
>
> calculate2' :: IO ()
> calculate2' = do 
>     let n = 40
>     putStrLn $ "Please enter a number to divide " ++ show n ++  " by: "
>     y <- readLn :: IO Int
>     x <- pure $ division n y
>     either (print . ("Oh no: " ++)) print x

Where the first function will be applied to the Left and the second to the Right.

The Applicative nature of Either

Say we wanted to check if the result is odd. The Functor nature of Either allows us to access the Right side with the use of <$> (fmap - see the previous article).

> calculate4 :: IO ()
> calculate4 = do
>     let n = 40
>     putStrLn $ "Please enter a number to divide " ++ show n ++  " by: "
>     y <- readLn :: IO Int
>     either print print $ odd <$> division n y 

So what happened here is that we fmaped the result of the division with odd. This is the equivalent of the Applicative:

> calculate4' :: IO ()
> calculate4' = do
>     let n = 40
>     putStrLn $ "Please enter a number to divide " ++ show n ++  " by: "
>     y <- readLn :: IO Int
>     either print print $ pure odd <*> division n y 

The great thing about it is that now we can essentially chain functions by using this new lifting functions pattern, while still maintaining the safe way of working with Either.

> calculate4'' :: IO ()
> calculate4'' = do
>     let n = 40
>     putStrLn $ "Please enter a number to divide " ++ show n ++  " by: "
>     y <- readLn :: IO Int
>     either print print $ pure oddDisplay <*> (pure odd <*> division n y)
>       where
>         oddDisplay x = if x then "Is Odd!" else "Is not Odd" 

Of course this could also be refactored to

> calculate4''' :: IO ()
> calculate4''' = do
>     let n = 40
>     putStrLn $ "Please enter a number to divide " ++ show n ++  " by: "
>     y <- readLn :: IO Int
>     either print print $  pure (oddDisplay.odd) <*> division n y
>       where
>         oddDisplay x = if x then "Is Odd!" else "Is not Odd" 

Further use of Either

Okay, but what if we wanted to chain two Eithers? Well a basic way of doing it would be again by pattern matching.

> calculate3 :: IO ()
> calculate3 = do
>     let n = 40
>     putStrLn $ "Please enter a number to divide " ++ show n ++  " by: "
>     y <- readLn :: IO Int
>     putStrLn $ "Please enter a number to divide the result by: "
>     z <- readLn :: IO Int
>     x <- pure $ division n y
>     case x of
>       Left e   -> print $ "Oh no:" ++ e
>       Right x' -> case division x' z of
>         Left e   -> print $ "Oh no:" ++ e
>         Right z' -> print z'

But this is a bit weird, because we are repeating ourselves, and we are also writing a lot of boilerplate code for something which in essence could be done a lot easier. Here comes the Applicative again.

> calculate3' :: IO ()
> calculate3' = do
>     let n = 40
>     putStrLn $ "Please enter a number to divide " ++ show n ++  " by: "
>     y <- readLn :: IO Int
>     putStrLn $ "Please enter a number to divide the result by: "
>     z <- readLn :: IO Int
>     either print print $ divide n y z
>       where
>         divide :: Int -> Int -> Int -> Either String Int
>         divide x y z = flat $ division <$> (division x y) <*> pure z
>
>         flat :: Either a (Either a b) -> Either a b
>         flat = either Left id 

Observe how we had to flatten the result. That’s a nifty trick that allows you to chain calculations with Either. Also observe how we had to lift z into an Either to allow us to <*> into the partially applied division. (If this doesn’t make much sense, try and write it from scratch and use the compiler to guide you through the above). Interesting thing about this flat is that it actually is a Monadic property - that is it exists in Control.Monad as join - and in essence it takes two nested monads and flattens them into one. Refactoring:

> calculate3'' :: IO ()
> calculate3'' = do
>     let n = 40
>     putStrLn $ "Please enter a number to divide " ++ show n ++  " by: "
>     y <- readLn :: IO Int
>     putStrLn $ "Please enter a number to divide the result by: "
>     z <- readLn :: IO Int
>     either print print $ divide n y z
>       where
>         divide :: Int -> Int -> Int -> Either String Int
>         divide x y z = join $ division <$> (division x y) <*> pure z

The Monad Instance

A last thing worth mentioning is that Either is Monadic as well. How do we leverage this? Let’s look at another example.

> calculate5 :: Int -> Either String Int
> calculate5 n = do
>     x <- n `divide` 2
>     x `divide` 2
>       where 
>         divide :: Int -> Int  -> Either String Int
>         divide _ 0 = Left "Can't divide by 0"
>         divide x y = pure $ div x y 

What we’re doing here is leveraging do notation to use Either’s Monadic structure and bind the result of the computation to a temporary x which gets divided again - all while maintaining the purity of the function. If we were to call calculate5 0 we would get the Left instance while any other call would return our Right result.

End

That’s it for now, hope you enjoyed it. Do you have any other nifty Applicative tricks. Message me on Twitter.

Until next time!

A look at the State Monad and StateT Monad Transformer.

Beginning to work with Monads is an important aspect of learning to work with Haskell. I wanted to add my take on some simple examples to try and add to the existing ones. So let’s have a look.

Let’s say

We have a web app and we need to monitor if a user is logged in or not across our session, and each of our functions return a result.

The code

Firstly we need to import our monad libraries. For this example we will be using:

import Control.Monad.IO.Class (liftIO)  -- ^ liftIO allows us to lift the output
                                        -- out of the monad and for example
                                        -- print or read, just like normal IO.

import Control.Monad.Trans.State        -- ^ the bog standard State Monad,
                                        -- together with the StateT Monad
                                        -- Transformer, which allows us to
                                        -- enrich the IO monad with the
                                        -- capabilities of State monad.

OK, I will try and comment the text as I go along, but so far so good. Let’s now define our two data types that we will use, based on the above web app assumptions.

data WebsiteResult = OK | Err String       deriving (Show, Eq)
data WebsiteState = LoggedIn | LoggedOut   deriving (Show,Eq)

So we know that the Website can return an OK or an Err + String information and all the state we want to track is if we are LoggedIn or LoggedOut. I hope this is all good until now. Let’s now have a look at defining an operation.

exOperation :: State WebsiteState WebsiteResult
exOperation = do
  logIn "Password"
  makeTransaction
  printResult

Arguably you can read what the exOperation does - without seeing the actual implementation (to which we will get to) of the operations. It first tries to login by providing a string "Password", then it attempts to make a transaction, and at the end it prints out the result. We can agree this is very neat. Furthermore if we look at the type of exOperation we can already get an insight into what it tells us. We read it as: we are operating with a State monad that is holding an instance of WebsiteState and at the end we are returning a WebsiteResult.

OK now let’s have a look at how we would go about implementing these operations.

logIn :: String -> State WebsiteState WebsiteResult
logIn password = do
  if password == "Password"  -- | check if it is the password 
    then put LoggedIn        -- | logged in
    else put LoggedOut       -- | logged out
  checkOk                    -- | at the end we check to see what happened

    where
      checkOk :: State WebsiteState WebsiteResult
      checkOk = do
        state <- get
        if state == LoggedIn then return OK else return $ Err "Bad Log In"

The first one takes a String, compares it to the (albeit hard-coded here) correct password. If it likes it, it changes the state to LoggedIn by using the put function. If it doesn’t then it changes it to LoggedOut. At the end I provided one more monad instance to show how we would change the return. In it we use the other useful function for the State monad, namely get which gets the WebsiteState out of the monad. Hopefully you are starting to get the gist of it, if not let’s look further at the other two functions:

makeTransaction :: State WebsiteState Bool
makeTransaction = do
  state <- get
  case state of
    LoggedIn -> return True
    LoggedOut -> return False

printResult :: State WebsiteState WebsiteResult
printResult = do
  state <- get
  case state of
    LoggedIn -> pure $ OK
    LoggedOut -> pure $ Err "Hi, enter your good password!"

These are mostly identical with the exception of one thing, namely the use of pure instead of return. It’s worth keeping in mind that both are identical, and it’s mostly to do with defining Applicative Functor.

Running the Monad

OK so all good, but how do we get the result of running the exOperation monad? Well to do this we need to use runState :: State s a -> s -> (a, s) which (as its type suggests) takes a State Monad and an initial State and returns the result of the calculation as a tuple of state and result. Perfect so let’s do it.

result = runState exOperation LoggedOut -- will return (OK,LoggedIn)

And if we wanted to get the result only and print it we could simply feed this to a fst in a IO () monad.

printOutResult :: IO ()
printOutResult = print $ fst result

But what if …

But what if we wanted to print out results as we went along, would that be possible? The answer is yes, but that means that we would need access to an IO monad instance while we are inside the State monad, which still behaves as we would expect IO to behave. This is exactly what StateT monad is for. Where State would have to have a signature of the type State Type1 (IO Type2) we can see from the signature that we don’t have (easy) access to Type2 - as it is wrapped inside the IO and we cannot reach inside to grab it. StateT allows us to make use of a type looking like StateT Type1 IO Type2 - hence now we can make use of both the State functions and the IO capabilities. Let’s look at the example, which I have annotated to make it easier to follow along.

--  If we wanted to combine this behaviour with an IO Monad we would need to use
--  the StateT transformer.

operations :: IO ()
operations = do
  putStrLn "Hello and Welcome to our Operations.\n Please insert your password:"
  pass             <- getLine
  let computation  = logInT pass
  let initialState = LoggedOut
  result           <- runStateT computation initialState
  return ()

-- | Observe how our return actually returns inside the IO Monad but our state
-- is outside of it. This offers us more control than something like "State
-- WebsiteState (IO WebsiteResult)" because we get a shallower version of the
-- monad, and we also get access to the 

logInT :: String -> StateT WebsiteState IO WebsiteResult
logInT password = do
  -- | First thing we get the state
  state <- get
  -- | Then, we check if we are already logged in.
  if state == LoggedIn
    then liftIO $ print "Allready Logged In!"
    else liftIO $ print "You need to sign in"
  -- | Now we get to check the password.
  if password == "Password"           
    then put LoggedIn                 
    else put LoggedOut
  -- | In the end we get the state again to check if the log in was successful.
  state <- get
  case state of
    LoggedIn -> liftIO $ print "Correct Password! Welcome!"
    _ -> liftIO $ print "Bad Password. Denied."
  -- | And at the end end we just return a random Auth Code.
  return OK

Worth noting here is that we could have just used return or pure to lift the IO operation, but the issue here is that it will not print or read it (best way to understand this would be to try it yourself), hence we need to use liftIO - this way we make sure that the IO operations happen as expected.

In the end

Hopefully this example helps you use State and StateT and gives a bit more insight.

Other Resources

• Simple StateT use
• State Monad

Or how to do the same thing with a different approach.

And a bit of Traversable

updated 2021-05-25

• Hackage Applicative Documentation
• Hackage Traversable Documentation

What are they?

Applicative

• An Applicative is short for a strong lax monoidal functor or some people might call it an Applicative Functor.

• In Haskell - it is a Functor that comes with an operation <*> :: f (a -> b) -> f a -> f b that tells it how to Apply a higher level Functor to another Functor.

• If you remember from the Functor article, we already defined what a Functor is and what fmap (aka. <$>) does - let’s compare them side by side:

<?> ::   (a -> b) -> f a -> f b
<*> :: f (a -> b) -> f a -> f b

• In essence the difference is that with <$> the function is flat - i.e. outside the realms of the Functor and it is injected inside.

• In <*> ( a.k.a. “splat” - as I have just found out during an interview earlier this week) the first argument is a lifted function - i.e. the Functor contains a higher order type.

• for Haskell to believe you a type is an instance of an Applicative it is sufficient to prove it has the functions:
  • pure of type Applicative f => a -> f a, and
  • either:
    • <*> of type Applicative f => f (a -> b) -> f a -> f b, or
    • liftA2 of type Applicative f => (a -> b -> c) -> f a -> f b -> f c.
• Other laws that it must satisfy:
  • Identity pure id <*> v = v
  • Composition pure (.) <*> u <*> v <*> w = u <*> (v <*> w)
  • Homomorphism pure f <*> pure x = pure (f x)
  • Interchange u <*> pure y = pure ($ y) <*> u
    • For the whole list with further conversation it would be good to consult hackage.

Scenario

Lets say we want to have a type Doer that stores both a type and its meta sign- which is a property we came up with.

The meta sign has the following behaviour: when we do operations with these type, the signs interact and the resulting sign follow the normal sign rule i.e. :

• + & + = +,
• + & - = -,
• - & + = -,
• - & - = +.

I would also like to introduce the use of GADTs in this case, as it makes working with the type nicer. Note that this could have been done without it, but I thought it would be clearer what we are doing by using them.

Implementation

• As mentioned before lets enable GADTs, and also let’s import the Applicative module

{-# LANGUAGE GADTs #-}
import Control.Applicative

• And continue by defining our types. Let us define the type Op which is our meta sign. We also implement a Show so we can display it nicely.

data Op = Add | Sub deriving (Eq)

instance Show Op where
  show o = if o == Add then "+" else "-"

• Now we can define our sign rule function that combines the two Ops.

signRule :: Op -> Op -> Op
signRule x y
  = case x of
      Add -> case y of
                Add -> Add
                Sub -> Sub
      Sub -> case y of
                Add -> Sub
                Sub -> Add

• But if we look, we can see a pattern - Op is a monoid where Add is the neutral element. So let’s make use of this and also enrich our type with another of its inherent - discovered properties.
• Note: algebraic properties are discovered and not designed - they are inherent to the type itself. You can design your types to make use of types that have the properties or not - but you cannot design the property into a type - if it doesn’t have it.

instance Semigroup Op where
  (<>) = signRule

instance Monoid Op where
  mempty = Add 

• Next let’s define our type Doer. In this implementation, our type constructor ON takes a meta sign Op and any type a and it creates an instance of Doer a - think of it like an embellished type that contains our meta-sign.

data Doer a where
  ON :: Op -> a -> Doer a
  deriving (Show, Eq)

• And let’s look at a few examples that would make it clear

ex0 =  ON Sub 3            -- ON - 3
ex1 =  ON Add "Hello"      -- ON + "Hello"
ex2 = [ON Sub 3, ON Add 2] -- [ON - 3,ON + 2]

We can see that Doer a is a Functor. Let’s prove it.

instance Functor Doer where
  fmap f (ON o x) = ON o $ f x

Now, let’s prove it is an Applicative.

instance Applicative Doer where
  pure                      = ON (mempty::Op)
  (<*>) (ON o f) (ON o' n') = ON (o <> o') (f $ n')

Note: we made use in (o <> o') of our previously discovered Monoid property. The reader (yes, you) can check that the rest of the laws of the Applicative Functor stand.

Examples

• OK I’m glad to say that we’ve covered most of the info regarding Applicative, some examples to see it in action would be good.

Example 1:

Let’s use our splat to apply the lifted function (+1) to a functor:

ex01 = ON Sub (+1) <*> ON Sub 1 -- ON + 2
--   = ON - (+1) <*> ON - 1     -- this is what happens
--   = ON ( - <> - ) (1 $ (+1))
--   = ON + 2

So it works as intended, we have the result of the operation and the result of the interaction between their meta signs.

Example 2:

We want to compose two functions and apply them to a Functor

ex02 = pure ((+1). (+2)) <*> ON Sub 3 -- ON - 6

Is there another way to write this? Of course, and it might give some insight into what actually happens:

ex03 = pure (.) <*> pure (+1) <*> pure (+2) <*> ON Sub 3 -- ON - 6

Explanation: we lift the composition, we partially apply it to the lifted (+1) we then apply it to the lifted (+2) giving us the lifted composition of (+1) and (+2). Then in the end we apply this to lifted 3 and we get lifted 6. As the functions are pure our meta sign is not altered.

Example 3:

We want to do the previous while changing our meta sign accordingly.

ex04 = pure (.) <*> ON Sub (+1) <*> ON Add (+2) <*> ON Sub 3 -- ON + 6

Isn’t that fantastic:

• we already know that 6 is the result of the function application
• - + - = + - which gets through to us in the type.

Example 4:

Say we have a list of Doers and a higher typed Doer and we want to fmap it.

ex2  = [ON Sub 3, ON Add 2]
ex05 = (pure (+1) <*>) <$> ex2    -- [ON - 4,ON + 3]

This is interesting - we can observe here what is going on - if we refactor again with something that we’ve seen before:

ex05' = (fmap (+1)) <$>  ex2    -- [ON - 4,ON + 3]
ex05''= fmap (fmap (+1)) ex2    -- [ON - 4,ON + 3]

This behaviour is linked to the definition of pure. But the added benefit of being able to interact through <*> is that it easily allows us to change the meta-sign.

ex06 = ((ON Sub (+1)) <*> ) <$> ex2  -- [ON + 4,ON - 3]

Observe how in ex06 the meta signs have flipped.

Traversable Time

What is it ?

• It is a typeclass that can be traversed from left to right - but its uses are a bit more subtle than that - and we’ll talk a bit more about it when time comes.

• I’m not going to go very in depth with regards to Traversable, because the post would fork too much (I will make a dedicated post at some point) - but it’s important to note that Traversable, Applicatives, Monads are very tightly connected. (The wiki article is a good read)

• Note: in the examples the Traversable, Foldable t is the [] type.

Examples

• Example: say we take a list of Doers and we want to nest it into a Doer type itself, with the correct meta-sign (the sign of folding all the meta signs inside the list with the <> we defined) while in essence unwrapping the elements. The type of this function would look something like:

squishSign :: [Doer a] -> Doer [a]

So here are the challenges we are facing:

• if we foldMap :: Monoid m => (a -> m) -> t a -> m we need to do quite a bit of work to to get our Doer to match that type - not ideal - and we are lazy.
• Wouldn’t it be nice if we had some sort of function that would traverse our list, do something with the type and then at the end gives us that something? Don’t worry Haskell has our back:

sequenceA :: (Traversable t, Applicative f) => t (f a) -> f (t a)

• observe how that t and f swap positions - that is what we want to do. We know Doer is Applicative, and we know that [] is Traversable so what are we waiting for:

squishSign :: [Doer a] -> Doer [a]
squishSign  = sequenceA 

I wrote it as a section as it reads a bit better - but let’s see it in action:

ex11 = squishSign [ON Sub 3, ON Add 2]           -- ON - [3,2]
ex12 = squishSign [ON Sub 3, ON Add 2, ON Sub 3] -- ON + [3,2,3]

Now we can apply some more functy (funky + functor) things we’ve seen earlier.

ex13 = pure sum <*> squishSign [ON Sub 3, ON Add 2, ON Sub 3] -- ON + [8]

This has been a well long post, and we’ve had a lot of functy time together. What other cool Applicative and Traversable design patterns do you use or have discovered? Let me know!

More reading

• Haskell Wiki Traversable

To begin with, it took a while to get used to it, but worked it in and in the end it turned out I really like it - and it works very well. So I thought that it might be worth sharing a few steps and insights into making a simple standard derivation.

Why NixOS

If you like declarative environments, changing your configurations, trying out new software, reproducible builds, etc. then NixOS is for you. You can work, configure, build, run programs in completely different environments and it is as easy as writing a nix derivation.

A tale of two derivations

What are we looking to do?

It’s important that we stick to the basics - let’s make two simple nix derivations. The first one will produce a file with that says “Hello World!” and the second derivation will use the first one and produce another file that says a different message.

From \null To NIX - A bit about the NIX language

NIX Functions

NIX the package manager uses its own lazy, pure, functional language to build derivations called NIX - and as you would expect functions play a major role in both NIX the language and NIX the package manager.

*I recommend you try these out in a nix repl instance. So let’s have a look:

f = x : x * 2

f 2 # -> 4

As you can see, all the functions are actual annonymous functions that can be bound to a variable. To have multiple arguments to a function we need to curry it:

f = x : y : x * y

f 2 3 # -> 6

Functions that take sets

A handy feature of NIX is the way it can manipulate and work with sets. For example:

We right sets like this:

{ a = 1;
  b = 2;
  c = "Text"; }

Note the use of ; to distinguish between elements of the set. So a function that works on a set would look like this:

f = s : s.a * s.b

f { a=2 ; b=3; } # -> 6

And with a named set:

b = { a = 3; b = 4; c = 5; }

f b # -> 12

Note that you can even explicitly grab these arguments from the set on the left hand side of the expression like so: (careful with the fact that when you destructure it on the right hand side it uses , always gets me)

f = {a, b} : a * b

Furthermore, NIX allows you to pass default arguments to your set defined functions: (also note that even if the set has only one element you still need to put the ; - also gets me every time).

f = { a ? 1 , b ? 2 } : a * b

f {}         # -> 2
f { a = 2; } # -> 4

Set Union

By the way, you can merge sets using the infix operator //. As the union of two overlapping elements the right hand side is maintained.

{a = 1;} // {b = 2;} # -> { a = 1 ; b = 2; }
{a = 1;} // {a = 2;} # -> { a = 2 ; }

List Concatenation

List concatenation is your usual suspect. ++

[ 1 2 ] ++ [ 3 4 ] 

Unexpected attributes

A thing to note is that there is a difference in declaring the variables of the set on the left or just declaring the set and destructuring on the right. The differe is that when it is on the left the function will not like it if you send it a set different to what it expects.

f = { a ? 1 , b ? 2 } : a * b
g = s : s.a * s.b

f { a = 1; b = 2; c = 3;} # -> will not work! because it has a c 
g { a = 1; b = 2; c = 3;} # -> will work

To allow for more flexible sets in your function you need to add ... to its expected arguments

f = { a ? 1 , b ? 2, ... } : a * b

f { a = 1; b = 2; c = 3;} # -> 2 all good

Also note that this way of writing it has the advantage of being able to give the arguments default values. So all in all, pick your weapon wisely.

Note: If you are like me and like static typing check out dhall is. I haven’t had the chance to use it much, but plan on doing so soon.

Lazy is good

Bein Lazy, means that every NIX file is essentially a set of expressions! So you can use import to import one file into another, and NIX will essentially import the other file as a set - that’s awesome. So for example:

File a.nix:

2

File b.nix:

{ b = 3; }

File f.nix:

s1 : s2 : s1 * s2.b

We can the open back up our nix repl and do the following:

a = import ./a.nix
b = import ./b.nix
f = import ./f.nix
f a b   # -> 6

That’s great if you ask me.

With Let In

Let and in allows us to intorduce terms on the go, while with allows us to avoid writing a lot.

The use of with makes a lot of sense when you realise that nested expressions always have the dot notation - and it can become tiresome. With gets rid of that by making all of the variables (while avoiding clashses) of a term available to the other term. For example:

Instead of:

let                         
  context = { a = 1; b = 2; };
in
  context.a + context.b

We can write:

let                         
  context = { a = 1; b = 2; };
in
  with context; a + b

Inherit

Inherit allows you to bring into the local scope, variables from outside the scope. It sounds more complicated than it is but here’s an example:

a = 2
b = 3
c = { inherit a b; c = 4; }

c # -> { a = 2; b = 3; c = 4; } swoosh!

Rec

Rec turns a set into a set where self referencing is possible. It’s handy as you can write out a sequence of lets and just grab one of them:

rec {
  a = 1032 - b;
  b = 3213 - c;
  c = 222;
  }.a # -> -1959 which is the value of a

Recursivity

To make use of recursivity you need to declare your function with a let

let f = x : y : if (y <= 0) then x else f ( x + 1 ) ( y - 1 );
in  f 3 4 # -> 7

Awesome.

NIX Types

Although not statically typed, NIX is strongly typed. So the basic types in NIX are:

Nix built ins

Nix has LOADS of builtin functions, which I’m not going to go through, but which you can easily discover by going into the nix repl, typing builtins. and hitting Tab. If you are a HaskellHead or any sort of functional fan you will see a lot of the usual suspects in there.

To learn what a function does, I sometimes do this thing where I type the function and evaluate it without an argument and then it will give some indication of what it is expecting. Somehow, I still haven’t found a great condensed easy to search resource for all the nix functions, but this works great - REPLS are fantastic.

Example

builtins.derivation 1  # error: value is an integer 
                       # while a set was expected, at (string):1:1 - oh! Okay
                       
builtins.derivation {} # error: required attribute 'name' missing, - ah, I see

# ... - you catch my drift 

But even cooler nix gives us builtins.derive.attrNames which gives us all the expceted attributes of a Set:

builtins.attrNames (builtins.derivation {})
# ->  [ "all" "drvAttrs" "drvPath" "out" "outPath" "outputName" "type" ]

Further reading

• link

The first derivation

Ok, so it is very important to get to grips with the language (to a good level) first I would say! Because afterwards you will se how nice and neat working with NIX is.

What is a derivation

A derivation is a NIX pkg manager defined set (if you would like). Every NIX derivation set must contain the following keys:

1. name - the name of the derivation,
2. system - the filesystem in which it can be built,
3. builder - the binary program that builds the derivation

Upon receiving a derivation, nix knows what to do with it. In essence it evaluates it and does some funky stuff with hashes, so that way you always get to save stuff in the right place. (I quite like cryptography and hashes and am unsure what the collision resistance of the hashing algorithm really is, but I haven’t heard of any collisions yet)

Let’s create our greeter derivation

Derivation 1

greeter.nix:

{
  pkgs    ? import <nixpkgs>{},
  message ? "Hello World!",
  sayHi   ? '' echo '\n ${message} \n' \ >> $out '', 
  ...
} : builtins.derivation({
  name    = "greeter";
  system  = builtins.currentSystem;
  builder = "${pkgs.bash}/bin/bash";
  args    = [ "-c" sayHi ];
})

Ok so what is the derivation actually? Well it is as we have seen from the tutorial above a function that takes in a set and returns the result of a derivation. In this case our function takes as parameters message and sayHi. As previously discussed we use the builitns functions to get the our current system and the builder is the nixpkgs.bash - it doesn’t get any more basic than this really. To bash we send first the argument -c which means execute the next arguments as commands, and then we send it an the sayHi script from the argument Set. If you look at the function you can see that we are outputing to an environment variable specifically $out. This is where NIX the package manager will save and store the output of our build. After running nix-build greeter.nix you should have a result symlink in your current folder that if you run cat on you will see our message. Great!

Derivation 2

As we said from the beginning, we want derivation two to build upon greeter and essentially do the same thing but with a different message. This is where NIX’s elegance comes into play.

greeter2.nix

let
  g = import ./greeter.nix {};
in
{ pkgs    ? import <nixpkgs>{},
  greeter ? import ./greeter.nix{
    message = "New Message";
  },
}:builtins.derivation({
  name    = "greeter2";
  builder = greeter.builder;
  system  = greeter.system;
  args    = greeter.args;
})

Ok, so in greeter2 we are essentially reimporting greeter1 and inheriting everything from it while just changing the message. But you might say this is not necessarily the point! We already have a function, that does this, why do we need to build another one?! Can’t we just change the argument we are sending to the function in the first place? And the answer to that is yes! - great spot

Derivation 3

greeter3.nix

{
  g = import ./greeter.nix { message = "Something else"; };
}

And that’s it! We’ve parametrised the build.

Conclusion

I realise this is a long post, and i might break it down. But hopefully it has been helpful and it gives you a place to start in the world of NIX. I highly recommend it.

Further reading

• nixOS wiki

# suppose this is your default.nix
# although I recommend separating the shell.
{
    pkgs ? import <nixpkgs>{}
}:rec{
  output = with pkgs;[hello cowsay];
  shell = pkgs.mkShell {
      name = "Shell";
      buildInputs = output;
      };
}

So now to build everything in output all you need to do is run:

nix-build default.nix -A output

which will subsequently generate all the derivations inside the list. And if you just wanted to run a shell with them you could do:

nix-shell default.nix -A shell

and you would be in a shell with all your needed binaries included.

Nesting

So this is probably where I would say this pattern comes in handy. Let’s say the above default.nix is actually inside a nested folder which we will call ./nest.

And we actually want to call the derivation inside our root folder ./.. The trick is to call them in the same way, from the root default.nix.

{
    pkg ? import ./nest {}
}
:let
  out = pkg.output;
in
  out

Zlib package Haskell

Working on my dissertation I wanted to have a nix-shell where I could test in a fast manner my web-interface for the FMCt. I was initially doing this:

{ release  ? import ./release.nix
, sources  ? import ./nix/sources.nix
, pkgs     ? import sources.nixpkgs{}
, FMCt-web ? import ./default.nix
}:
pkgs.mkShell {
  nativeBuildInputs = with pkgs;[
    cabal-install
    ghcid # ghcide
    gnumake               # makefile
    haskellPackages.aeson
    haskellPackages.blaze-markup
    haskellPackages.hlint # linting
    haskellPackages.scotty
    haskellPackages.zlib
    haskellPackages.ghc
    rlwrap                # to be able to easily re-enter last input when in the repl
  ];
}

The issue I was having was getting the following error:

<command line>: can't load .so/.DLL for: libz.so (libz.so: cannot open shared object file: No such file or directory)

Which was very annoying, as I thouth I was provisioning both the environment and the package for haskellPackages.zlib. Where I was wrong was in the following bit: making the haskellPackages available to the environment is only useful if we need the executables. If we need the libraries the correct way to do it is the following:

{ release  ? import ./release.nix
, sources  ? import ./nix/sources.nix
, pkgs     ? import sources.nixpkgs{}
, FMCt-web ? import ./default.nix
}:
let 
  # add ghc packages that should be available to the ghc here
  ghc = (pkgs.haskellPackages.ghcWithPackages (
    hpkgs: with hpkgs;[
      zlib
      scotty
      aeson
      blaze-markup
      aeson
    ]
  ));
in
pkgs.mkShell {
  nativeBuildInputs = with pkgs;[
    cabal-install
    ghc
    haskellPackages.hlint # linting
    # ... 
  ];
}

This was very helpful for me to see, that actually it is not the environment that needs to be provisioned, but rather ghc itself. Hence why ghcWithPackages solved the issue.

Monoids

Coming from the world of algebra, a monoid is a :

• semigroup with an identity, which is a:
  • magma with associativity, which is a:
    • closed set, with a binary operation which is closed under it

So what?

Well believe it or not, Haskell defines a Monoid as a Typeclass, that lets you do funky stuff. Great!

Let’s have a go and demonstrate these funky useful stuff.

Use case

Say we have a parser that takes a list or stream of numbers and checks if any of them are any of the following:

1) odd

2) divisible by 4

3) divisible by 6

… (you can carry on imagining adding rules here)

First Solution

The first solution would be pretty straight forward:

s1 = [2,4,5,7,5,3] -- this one checks
s2 = [1,1,1,1,1,1] -- this one doesn't

check :: [Int] -> Bool
check []      = False
check (x:xs)  =  odd x  || x `mod` 4 == 0 || x 'mod 6 == 0 || check xs

That’s all nice and tidy, but say you wanted to add another test - it can be a bit annoying to chain another || test x to the previous expression. So what else can we do?

Second Solution

Well, we can make an observation that all the functions:

1) are of the type Int -> Bool,

2) we have a list of [Int],

3) our type is check :: [Int] -> Bool.

So in essence we need a way to take a list of [Int->Bool] tests, and map them to [Int]. Then we flatten the list, and repeat until we get to the end of the list of [Int] or we get True after we flatten.

check' :: [Int] -> Bool
check' []      = False
check' (x:xs)  = foldl1 (||) ( map ($x) tests) || check' xs
  where
    tests = [ t1, t2, t3 ]
    t1 = odd
    t2 = \x -> x `mod` 4 == 0
    t3 = \x -> x `mod` 6 == 0

And realistically, even this form, if we look at the recursivity of check' we can improve by observing that check' is very much a map.

check'' :: [Int] -> Bool
check'' = foldr1 (||) . map (\x -> foldl1 (||) ( map ($x) tests))
  where
    tests = [ t1, t2, t3 ]
    t1    = odd
    t2    = \x -> x `mod` 4 == 0
    t3    = \x -> x `mod` 6 == 0

Ok, I know what you are thinking, that might not be the nicest section ever, but Haskell allows us to make it nicer by taking that aux function and declaring it as such:

check'' :: [Int] -> Bool
check'' = foldr1 (||) . map aux
  where
    aux x = foldl1 (||) (map ($x) tests)
    tests = [ t1, t2, t3 ]
    t1    = odd
    t2    = \x -> x `mod` 4 == 0
    t3    = \x -> x `mod` 6 == 0

Option 3

Ok so we’ve done it in a more flexible way, but where does the Monoid come into play. Well if we remember the properties from the introduction and we have a look in ghci at the :info Monoid we find out a few things. From Semigroup typeclass we get:

1. We have a function mappend that has the type signature Semigroup a => a -> a -> a. So what this does is takes two elements, applies the monoids operation and returns the result.

2. We have this other function mconcat with the signature Semigroup a => [a] -> a. This one takes a list of elements and flattens it with the binary operation.

3. We find out that [a] (so any list) is a monoid.

4. We find out about the existence of All and Any two Monoids. When we look at their info: All and info: Any we find out that they are a newtype Any = Any {getAny :: Bool}. Nice!

So let’s try and get these to work for us.

Let’s start by defining our tests as higher order monoids first:

newtype Tester a = Tester {getTest :: a -> Any}
instance Semigroup (Tester a) where
  f1 <> f2 = Tester $ \x -> (getTest f1) x <> (getTest f2) x

instance Monoid (Tester a) where
  mempty = Tester (\x -> Any False)

Awesome, the type checks (that’s a good hint that the rules might be good) and we can also see that the Monoid laws hold(left as an exercise for the reader). Also by using the Monoid Any in the type signature we know we can further flatten it. So our function now becomes a lot clearer/cleaner, and nicer:

check''' :: [Int] -> Bool
check'''   =  getAny . mconcat . map aTests
  where
    aTests = mconcat $ map (getTest . Tester) lstT
    lstT  :: [(Int -> Any)]
    lstT   = [t1,t2,t3]
    t1     = \x -> Any $ odd x
    t2     = \x -> Any $ x `mod` 4 == 0
    t3     = \x -> Any $ x `mod` 6 == 0

And now let’s transform those tests into sections, as they read nicer:

check'''' :: [Int] -> Bool
check''''  =  getAny . mconcat . map aTests
  where
    aTests = mconcat $ map (getTest . Tester) lstT
    lstT  :: [(Int -> Any)]
    lstT   = [t1,t2,t3]
    t1     = Any . odd 
    t2     = Any . (==0) . flip mod 4 
    t3     = Any . (==0) . flip mod 6 

And as suggested here (thank you for the suggestions) we can further neaten it up by using the infix notation for mod together with partial application:

check  :: [Int] -> Bool
check = getAny . mconcat . map aTests
  where
    aTests = mconcat $ map (getTest . Tester) lstT
    lstT  :: [(Int -> Any)]
    lstT   = [t1,t2,t3]
    t1     = Any . odd 
    t2     = Any . (==0) . (`mod` 4)
    t3     = Any . (==0) . (`mod` 6)

We can extend this type of manipulation to most monoids, and internalising the rules and general capabilities can lead to pretty awesome solutions, and applications.

Further Reading

• wiki.haskell

Roger out!

• in the world of Haskell, usually you can think of it as a type constructor with some special properties. It takes an object and it wraps it.

• Functors are the building blocks of most typeclasses in Haskell

  • If that sounds like a bold claim, Have a look here to convince yourself

• Functors are (by definition) the pipes between categories - you might be using them already without realising

Use case

We use Functors all the time - it is hard to think of a case where you wouldn’t use it.

The Identity Functor

Let’s create the simplest functor possible

data Identity a = Identity a deriving (Eq, Ord, Show)

instance Functor Identity where
  fmap f (Identity m) = Identity $ f m

• TL;DR What does it do?

  • Transforms whatever you give to it into the Identity type.

• What does it need to implement to be a Functor?

  • fmap aka <$> with the type signature (a -> b) -> f a -> f b. It is pretty intuitive this one takes a function from a -> b and transforms the functor f a into a functor f b. Easy.

• What laws does it need to satisfy?

  • it must preserve the identity morphism

    • fmap Id = Id

  • it also must preserve composition of morphisms

    • fmap (f . g) = fmap f . fmap g

• A few examples using our Identity functor:

fmap (+3) $ Identity 3 -- 6
(*2)  <$> $ Identity 4 -- 8

• Other functor functions:

<$ :: a -> f a -> f b

• It’s half the fmap to the left (if that makes sense?). You give it an element and then you give it a functor, and it returns the element wrapped in the functor (a bit like it pushes the element out of the functor and replaces it with what is on the left).

• an example:

  5 <$ Identity 6  -- Identity 5
  

• That is quite neat. You can even use it with higher types for example:

(+1) <$ Identity 5 -- of the type :: Num a => Identity (a -> a)

Do you see what happened? We now have a higher order Identity type - a function wrapped in Identity. But what can we do with it? Well we can apply it - with fmap again.

fmap ($5) ((+1) <$ Identity 3) -- Identity 6

• We basically flipped the roles of the function and application. And of course ($5) :: (a -> b) -> b is a function that takes a function and it applies to 5.

• Also, if you import Data.Functor you get $> (which is as you guessed the opposite of <$) and void which is :: f a -> f (). Pretty straight forward.

In the end

That was it for today. I will try and make an article on each typeclass of Haskell as I am quite enjoying writing these. The next one will probably be on Applicative Functors, which you probably know where it leads to.

More reading

These are all very basic applications and simple examples. But if you are curious here is some further reading:

• Bartosz Milewski’s Book is a fantastic resource
• HaskelWiki
• HaskellForAll Article
• Haddock

What does it do

Thread last is very cool. In essence it takes the result of your one function call and threads it in front of another one. Let me show you what I mean

(->> 1 
     (+ 2 ) 
     (+ 3 )
     (+ 4 )) ; -> 10

And the more explicit version of it

(->> 1       ; let's call it X to see it
     (+ 2 )  ; this gets transformed to (+ 2 X), let's call the result of this Y
     (+ 3 )  ; this gets transformed to (+ 3 Y), let's call the result of this Z
     (+ 4 )) ; this gets transformed to (+ 3 Z)  whic is then equal to 10

Pretty cool , because otherwise the operation would have been written as :

(+ 4 (+ 3 (+ 2 1)))

In this case it is not the worst - but the longer the calls the more complex the calls the more you would need to read from inside out.

CLisp doesn’t have this

Or at least yet CLisp doesn’t, I read somewhere that Clisp 21 does. But, let us have a go at implementing it

(defmacro ->> (var &rest lst)
  (if (car lst) ; if the lists of remaining operations is not empty
      `(->> (,@(car lst) ,var) ,@(cdr lst)) ; recursively call the macro
      `,var)) ; otherwise, return the var.

So what the above macro is recursively create the call. Let’s run through the above example step by step to see the macroexpansion

Step by step Macroexpansion

Step 0 - The call itself

(->> 1
     (+ 2)
     (+ 3)
     (+ 4))

or inline it would be

(->> 1 (+ 2) (+ 3) (+ 4))

Step 1 - The first macro-expansion

(->> (+ 2 1) (+ 3) (+ 4))

So we see, the macro takes the first element of the list and the first element of the arguments and places the it at the end of this call. Then it recursively calls itself again.

Step 2 - The first macro-expansion (again)

(->> (+ 3 (+ 2 1)) (+ 4))

It treates (+ 2 1) as it treated 1 and it appends it to the car of the opperation list

Step 3 - You guessed it, the first macro-expansion (again)

But this time it is the second branch of the if

(+ 4 (+ 3 (+ 2 1)))

Step 4 - Rejoice

… and marvel, at how easy it was to implement the feature of clojure in common lisp using a simple recursive macro.