Disfunctional

Monads as I understand them

Sun, 02 Dec 2012 19:27:00 -0800

To be honest, it took me a ton of tutorials - a ton - before I could look you in the eye and say I understand what the hell a monad is.

I believe the reason for this is not because they are hard, but because all those tutorials didn’t build upon my basic understanding of functors. Functors are much easier to understand. If you need a refresher read this: http://drboolean.tumblr.com/post/25413244757/functor-i-hardly-knew-her

Or have a play with them yourself: https://github.com/loop-recur/typeclasses

In this post, I hope to take the quickest path to explaining monads without taking all the detours due to their vast usage and abstract nature.

Why we have monads in the first place

What follows is our naive program. In a perfect world we could write this:


//+ getUser :: Number -> User
var getUser = db.find('users');

//+ parseUrl :: String -> Number
var parseUrl = compose(pluck(1), match(/users\/(\d+)/));

//+ urlToUser :: String -> User
var urlToUser = compose(getUser, parseUrl);

Our entry point is urlToUser. It will take a url string to parse and extract the id from then it will give that to getUser to find our user.

I said this representation is naive because there are a few places we can fail. Let’s start with it failing on the parseUrl function. This function may or may not find a match from our match(/users\/(\d+)/) and it will blow up with a TypeError: Cannot read property ‘1’ of null if it can’t!

This will never do. Since every monad is a functor and functors are easier to understand, lets start there. Functors to the rescue!


//+ getUser :: Number -> User
var getUser = db.find('users');

//+ parseUrl :: String -> Maybe(Number)
var parseUrl = compose(fmap(pluck(1)), Maybe, match(/users\/(\d+)/));

//+ urlToUser :: String -> Maybe(User)
var urlToUser = compose(fmap(getUser), parseUrl);

What we had to do is place our match result into a Maybe. This forces the rest of our code to deal with the fact that we may or may not have a match in pluck(1) and getUser.

The real thing to think about here is what we’ve done typewise. In urlToUser, we’ve composed parseUrl :: String -> Maybe(Number) with getUser :: Number -> User. Those types shouldn’t line up since getUser takes a Number not a Maybe(Number). Through the magic of fmap which opens up our Maybe and runs the function on it’s innards, we pass our Number to getUser instead of the Maybe(Number) and all is well.

You could say we composed these types:

a -> F(b) (parseUrl)

b -> c (getUser)

And ended up with:

a -> F(c) (urlToUser)

Where F is the functor (in this case Maybe). K, great. We understand functors and all that, but what about monads?!

Getting more robust

Well, we caught the first failure case, but there’s another one. What if getUser doesn’t actually find a user?! Total code anarchy. Let’s catch this case now*:


//+ getUser :: Number -> Maybe(User)
var getUser = compose(Maybe, db.find('users'));

//+ parseUrl :: String -> Maybe(Number)
var parseUrl = compose(fmap(pluck(1)), Maybe, match(/users\/(\d+)/));

//+ urlToUser :: String -> Maybe(Maybe(User))
var urlToUser = compose(fmap(getUser), parseUrl);

Darn it. We wanted urlToUser to return a Maybe(User), but we returned a Maybe(Maybe(User)). Since fmap re-wraps up the type for us and getUser returns a Maybe too, we get a nested Maybe that we need to flatten. This is precisely the time to use a monad. Luckily, Maybe is a monad in addition to being a functor.

There is this great function called mjoin that we need to use. It’s specific to each monad instance. For Maybe it works like this:


mjoin(Maybe(Maybe("hello monad"))) // Maybe("hello monad")

mjoin(Maybe(Maybe(null))) // Maybe(null)

	

//+ urlToUser :: String -> Maybe(User)
var urlToUser = compose(mjoin, fmap(getUser), parseUrl);

Boom! We just flattened the instance and we’re good to go. Congrats, you just used the Maybe monad! It was really that easy.

So back to types. We needed to compose parseUrl :: String -> Maybe(Number) with getUser :: Number -> Maybe(User). This is exactly the pattern we want to recognize as monadic composition or in other words, composing two functions that take normal values, but return monadic values. Here’s the abstract pattern:

a -> M(b) (parseUrl)

b -> M(c) (getUser)

And ended up with:

a -> M(c) (urlToUser)

We used M for monad in the types above instead of F for functor since we’ll need the ability to call mjoin on it afterwards to flatten it up.

So monads are functors that flatten?

Well, yes…but it goes further than that. Just stay with me here as we go through the final trick.

If we wanted to compose lots of monadic functions it would get real awkward real fast since mjoin only flattens our values once and we’d see a lot of compose(mjoin, fmap) everywhere.

The real power of monads comes from our mbind function. This function is defined as just the combination of fmap and mjoin as you would expect, but with a few quirks:


//+ mbind :: M(a) -> (a -> M(b)) -> M(b)
var mbind = function(mv, f) {
  return compose(mjoin, fmap(f))(mv);
}

The first thing to notice is we’ve flipped the arguments to around (value, then function). This is because it’s setup for chaining/nesting. Check it out:


//+ addMaybes :: Maybe(Number) -> Maybe(Number) -> Maybe(Number)
var addMaybes = function(ma, mb) {
  return mbind(ma, function(a) {
    return mbind(mb, function(b) {
      return Maybe(a + b);
    });
  });
}

addMaybes(Maybe(3), Maybe(4)) // Maybe(7)
addMaybes(Maybe(null), Maybe(4)) // Maybe(null)

This is just like our node.js “pyramid of doom” nested callback style. The reason that’s so powerful is that:

1. We can depend on the values from the previous expressions

We get access to a and b to use together. We can keep mbind-ing deeper and deeper and pretend as though all the values have succeeded and are there.

2. We can prevent the nested functions from running all together

If anything isn’t there, we’ll never reach the following function since Maybe won’t even run it. And since the rest of the functions are nested the whole process gets shut down right then and there.

Both of these features are unique to monads and are what make a them more powerful than functors/applicatives. So use that when you’re making a decision on whether or not you need to use a monad or not. Usually it’s better to not use them if you can get away with something simpler.

Lastly, …for now

There’s a whole lot of monad stuff to learn. I could talk about pointed functors and keeping it type generic by using mresult, I could talk about mcompose or ap or the monoid instance MonadPlus, but I wanted to point out one last little feature for now. liftM

liftM keeps us point free and simple. It works just like fmap, but for monads:


//+ addMaybes :: M(Number) -> M(Number) -> M(Number)
var addMaybes = liftM("+");

liftM(function(x){ return x + 1; }, Maybe(4)) // Maybe(5)

liftM(function(x, y){ return x + y; }, Maybe(4), Maybe(5)) // Maybe(9)

liftM(function(x, y){ return x + y; }, Maybe(4), Maybe(null)) // Maybe(null)

When liftM is given multiple arguments, it nests each value as if we were writing our mbind manually.

So there you have it!

*Something to mention is that db.find should probably return a Maybe(a) by design. This would force us to deal with the nulls and make our program more robust from the start. If you contrast that to just returning null like we did in the previous example, you can see that these types really do help you write a more correct program.

Tail call optimization on it's way... Who gives a frak?!

Sun, 30 Sep 2012 19:40:00 -0700

I’m going to talk about capturing different recursive patterns in higher order functions and how we are better off with them over explicit recursion anyways. But first, let’s quickly go over what recursion is in javascript and why we might care about it.

Recursion in javascript

What is recursion? Well, it’s just calling a function from within itself. It is usually used as a replacement for loops in functional languages.

Let’s define a recursive version of Array#reverse. We need a couple of helper functions: head and tail.


head = function(xs) {
  return xs[0];
};

tail = function(xs) {
  return xs.slice(1, xs.length);
};

head will grab the first item in an array and tail will return everything but the first item. Now then, reverse!


reverse = function(xs) {
  if(xs.length == 0) return xs;
  return reverse(tail(xs)).concat(head(xs));
}

reverse([1,2,3,4]) // [4,3,2,1]

First, we create a base case that returns the empty array if the length is 0. This prevents us from looping forever. Then, we just concat the first item with the result of calling this function recursively on the tail, essentially sticking it on the end of the new array we’re building.

When I first was acquainted with recursion, I kept trying to visualize the stack and each step in the process. Now, I find it much easier to just mentally replace the recursive call with what would be the result. In this case, that would be return [4,3,2].concat(1);

Okay, on with the show

reverse doesn’t have to be defined recursively. We can use a good old fashion loop.


reverse = function(xs) {
  var result = [];
  
  for(x in xs) {
    result = [xs[x]].concat(result);
  }
  return result;
}

There are some benefits of recursion. It’s elegant, it reads well, it’s not creating messy variables to keep state or reassigning/destroying them. But in javascript, it is not very practical. For one, the syntax is a bit clunky. If you contrast this with an erlang or haskell example, it highlights how unnatural recursion is in javascript. Here’s haskell:


reverse [] = []
reverse (x:xs) = reverse xs ++ [x]

The (x:xs) part uses built in pattern matching to extract the head from the tail of the array. Also we can define the function twice - once for the base case.

A second reason recursion isn’t very practical in javascript is the compiler is not optimized to keep track of all the recursive calls. They say tail call optimization is coming, which is a compiler trick to release memory during each iteration, but I say don’t worry, we can do better than both of these…

A better way


reverse = reduce(function(acc, x){ return [x].concat(acc); }, []);

Check that out! We don’t have to specify any iteration at all. We can just leave it to the reduce function to figure that out. I’ve used partial application here and only gave reduce two of it’s three arguments.

What’s more, since I’m familiar with the function, I know just by reading the word reduce that we’re capturing a specific recursion pattern where the base case is an empty list and for each iteration we apply a function to an accumulator and the element from the list. Here it is explicitly:


reduce = function(f, acc, xs) {
  if(xs.length == 0) return acc;
  return reduce(f, f(acc, head(xs)), tail(xs));
}

Now, reduce isn’t actually implemented using this recursion pattern above for performance reasons, but that makes no difference to us. We captured the pattern in a named abstraction (reduce) and now we’re unshackled from the chains of iteration…or something like that.

The pattern we just witnessed was a catamorphism - your basic fold.* In fact, most languages call reduce foldl for fold left.

Our beloved map is just a specific implementation of this recursion pattern. So is filter. That means we can implement each of these methods in terms of reduce.

But wait, there’s more

There isn’t just one type of recursion pattern out there. There are a number of them and each have their own qualities. For instance, if, in addition to the accumulator and current element, you want access to the rest of the array during each iteration use a paramorphism.


paraReduce = function(f, acc, xs) {
  if(xs.length == 0) return acc;
  return paraReduce(f, f(acc, head(xs), xs), tail(xs));
}

This is just like the catamorphism, except that we pass the extra xs into the supplied function.

On top of instant recognition of the named pattern, DRY code, and easy swapping of recursion strategies, we’ve opened the door to different implementations of our underlying loop. That means we can optimize under the hood.

There’s a law (via functors) that states the following:


compose(map(f), map(g)) == map(compose(f, g))

So instead of looping through the whole array and running g, then doing the whole thing again and running f, we can just make 1 loop and run compose(f, g) for the same result.


// not fused
compose(map("*2"), map("+1"))

// fused
map(compose("*2", "+1"))
}

We can also use our abstractions to run in parallel or add any other optimizations you can imagine. If we had two explicit loops going on there, it’d be very difficult to make this kind of change. The point is when you program declaratively you leave room for different implementation.

A vulgar display of explicit iteration

So in conclusion, I say frak the tail-call optimization! We’re reaping the all benefits of abstraction, labeling our patterns for easy understanding, writing smaller, more concise code…why did we want all this messy recursion back in our applications again anyways?

*Hopefully, I’ll do a post on anamorphisms (or unfolds) soon. Until then, check out this paper

I do declare

Sun, 22 Jul 2012 11:32:00 -0700

Brian vs Abstraction Round 1

Martin Fowler once said something to the effect that programming, at it’s finest, should be nothing more than the configuration of abstractions. This made a little bit of my brain leak out my ear the first time I read it. It was a statement that made me question everything I’d written up until that point. It was brilliant! I was going to make abstractions, then configure them in every application from then on out. No more inline, single use nonsense.

Over the next week at work, after spending half of each day abstracting things, I realized that no one really has the time to pull this off. It’d have to be a group effort: Everyone making super configurable abstractions and explaining to each other how to use them via doc or tutorial or whatever. But things keep changing, the ground moves below our feet, technology, languages, etc. It was useless to try to abstract everything.

But back then, I hadn’t seen the whole story. I was trapped in OO land where nouns and specific implementations dominated. Where functions were tucked away for use with only their owning objects. Where the specific application’s data was tangled up with the very functions we were trying to make data agnostic. Where generic behavior was forced into the back alleys of abstract interfaces. Now, after functional programming changed my perspective, I could revisit the dream.

In functional programming, we build bigger systems from the same old reusable set of functions. We look at shared behavior and functionality more like traits and say a thing is a functor or a monoid, not an address or a user. We create contexts so we can use those same functions in different ways on different things, but in the end, it’s the same set of functions. The dream may be possible after all!

Brian vs Abstraction Round 2

Anyways, this is a post on declarative programming. Declarative programming gets to the heart of what Fowler was saying as we will see.

Declarative programming is where you say what should happen in your application and walk away - you don’t actually do anything. You then allow the underlying mechanism, be it a framework or language or some other (higher order) code, to accomplish the tasks however it sees fit. Imperative programming, on the other hand, is where you take the reigns and tell the computer how to do each step right then and there in the midst of your business logic.

Maybe that’s not the most unbiased definition, but let’s keep digging and you’ll see what I mean. The primary example I see everywhere is SQL. You express a query as a single expression and let the computer do it’s job. This is much different than say, a typical c program where you specify each individual step down to memory allocation right there in your function.

Another example is relationships in rails. ActiveRecord users will recognize the example of adorning models with has_many and belongs_to. You declare the relationship and leave it to the superclass to make it happen.

There are many benefits to this style of programming. Most of them stem from the fact that you’re kind of forced to abstract all the functionality in order to write a declarative line. But the style itself leads you to an agile application that reads like a book if you do it right.

Here’s a bite size example:

Imperative


var chargeCard = function(credit_card) {
  if(chargeCard(credit_card)) {
    sendReceipt(credit_card);
    updatePaidStatus(credit_card);
  } else {
    cancelAccount(credit_card.user);
  }
  return credit_card;
}

Declarative


//+ chargeCard :: CreditCard -> CreditCard
var chargeCard = ifelse(chargeCard, compose(updatePaidStatus, sendReceipt), compose(cancelAccount, '.user'));

You might initially think they are about the same, except the declarative one is much worse on the eyes. But wait, there are some hidden benefits beside brevity. For one, the declarative version has the ability to alter the strategy of how these functions work together. Just by changing compose, we might parellelize some things or we could alter ifelse to do some tracing in between each step.

Another benefit is the ability to compose small pieces together to build up a bigger, more readable function. One expression of self contained bits can be manipulated much easier than several lines of separate steps with loose variables and such lying around. You simply copy and paste little chunks of code around and wrap them in compose.


//+ cancelUsersAccount :: CreditCard -> void
var cancelUsersAccount = compose(cancelAccount, '.user');

//+ finishPayment :: CreditCard -> CreditCard
var finishPayment = compose(updatePaidStatus, sendReceipt);

//+ chargeCard :: CreditCard -> CreditCard
var chargeCard = ifelse(chargeCard, finishPayment, cancelUsersAccount);

And and there it is. If you look at chargeCard, there’s that declarative “what” I was looking for written out in plain english.

Showing off

Let’s do a few optimizations to show off a bit.


//+ cancelUsersAccount :: CreditCard -> void
var cancelUsersAccount = memoize(compose(cancelAccount, '.user'));

//+ finishPayment :: CreditCard -> CreditCard
var finishPayment = compose_p(updatePaidStatus, sendReceipt);

We’ve just memoized(cached) the cancelUsersAccount function so it doesn’t actually run that function twice with the same user - it will just return the result the second time. Usually, that helps with long calculations, but in this case it just prevents us from accidentally running a db call again for no reason since it’d already be cancelled. Then we sendReceipt and updatePaidStatus in parellel with the use of compose_p*.

And perhaps, we’d also like to parallelize the whole charge process itself. Instead of a manual, imperative loop, we can use the declarative abstraction for iteration. Here’s the imperative loop:


var results = [];

for(credit_card in credit_cards) {
  results.push(chargeCard(credit_card));
}

runReport(results);

And here’s the declarative one:


map_p(chargeCard, runReport, credit_cards);

In this case, we used map_p instead of a normal map. This takes a function to run, a callback, and an array.

People say I’m just a dreamer…

So declarative programming says what should be done and lets the underlying code decide what to do. Imperative, order of execution style programming has a funny way of hindering that freedom. Like doing our own garbage collection in code, when we hard code these low level steps, we steal responsibility away from the compiler or interpreter or preprocessor or framework or language or other code or whatever and place it right in the middle of in our application.

This has many benefits. Perhaps, we should no longer fear premature-optimization as much anymore. Bug fixes can be made without touching your app. Good people like the SQL folks can make their functions better and you don’t have to change a single line to reap the benefits.

Ladies and gentlemen, we’ve risen to a higher level. The dream of abstracting the world may be come true after all.

* The compose_p function uses setTimeout in my version on functional.js. This works because I typically program javascript in the appcelerator titanium platform, which will thread on timeouts. However, you can alter it to thread in many different strategies that work for you.

Functor, I hardly knew her!

Mon, 18 Jun 2012 20:57:00 -0700

I’m here! I’m at that special moment where I just realized why the heck functors matter. At first I knew the types and I knew the ideas, I just didn’t understand why it mattered.

I think the root of my misunderstanding was my OO background and confusion about the job of types in the functional realm. I’m gonna write a post about that tomorrow, promise.

The big revelation came when I was using flapjax (flapjax-lang.org). There is an object called Behavior that holds a value. To run a normal function on that value, you have to call liftB. That will then pull the value out of the behavior, run your function with it, then put it back in. Like this:


var myBehavior = new Behavior("Jimmy");
var updateUI = function(name){ $("#username").text(name) }
var newBehavior = liftB(updateUI, myBehavior);

Flapjax is awesome, but nevermind that right now - the details aren’t important. The important part is that the Behavior is actually a Functor. And liftB should just be fmap.

This blew my mind because I realized how many things out there are actually functors. Let’s dig in and then maybe look back at this code and hopefully you can see what I mean (if i do a good job of explaining it).

So what’s up with Functors?

Lets forget about the mathematical aspects for a bit. And besides, I’m not the guy to explain that anyways.

What a functor does is let you run a normal function that expects a normal type, like a string or integer, with a fancy type, like an object. A nice way to say that is you map a function over a type.

Let’s start with a brilliant example.

We have an object/type that’s called Observable. I’m using objects and types interchangeably here.


var Observable = function(x) {
  return {val: x};
}

var o_name = Observable("brian");

Admittedly, it’s not that observable just yet.

We’d really like to run a normal function like reverse on our brand new observable, but we’ve stuck our string “brian” inside of this object and reverse doesn’t work on that object. Enter fmap.

fmap is a universal name (just like map) for mapping a function over a type. I’m guess it stands for function map or functor map. Since functions are sometimes called maps in category theory, I guess function map would be redundant. But anyways.

Let’s make our object a functor by giving it an fmap implementation.


var Observable = function(x) {
  
  var fmap = function(f) {
    var new_val = f(x);
    if(new_val != x) fireEvent('changed!', {val: new_val, previous_val: x})
    return Observable(new_val);
  }
  
  return {val: x, fmap: fmap};
}

There we go. Check it out. So we take a function, and get new_val by running it over our previous value (in this instance “brian”). Then if the two values aren’t the same, we fire an event that it was changed with some information passed along in the event about old and new values. Finally, and this is the important part, we wrap our new value back in our Observable and viola! we’ve run a normal function on our type.

Since fmap is kind of universal, we can define a nice function that will work on any functor instance (that is, any instance that implements fmap).


var fmap = function(f,o) {
  return o.fmap(f);
}

And our final code is this:


var o_name = Observable("brian");
fmap(reverse, o_name); // Observable("nairb")

And there you have it!

Part of what’s great about this is our ability to run normal everyday functions on our objects. We needn’t define the same old stuff from object to object as long as we implement a way to map (fmap) over it. Another reason you’ll want to wear your Functor pants to work tomorrow is that we’ve got the ability to actually alter the functions behavior while running inside our object.

Let’s look at one more example. It’s our old friend Maybe.


var Maybe = function(x) {
  var fmap = function(f) {
    return isFalsy(x) ? Maybe(null) : Maybe(f(x));
  }
  
  return {val: x, fmap: fmap};
}

//+ getProduct :: Number -> Maybe(Product)
var getProduct = compose(Maybe, db.find('products'));

//+ nameOfProduct :: Number -> Maybe(String)
var nameOfProduct = fmap(pluck('name'), getProduct);

nameOfProduct(3) // "hella t-shirt"

Here, if the product doesn’t come back, we won’t blow up when we read it’s name. Maybe just checks to see if the value’s there before it runs a function on it.

What’s more, we could make db.find return a functor too. We could say the call itself is an instruction to get the record and by fmapping something over it, it will actually make the db call.

In conclusion

We’re really just abstracting function application. Any object could be a functor, but you usually want to stick with a behavior type object with a single value.

. The technical term for this stuff is that we’re lifting a function into a computational context. That makes sense since the context can change the behavior of our normal functions. In the case of Observable it adds behavior by notifying the authorities of change. In the case of Maybe it might not run it at all.

So the intuition is that you can run a normal function on the value(s) inside a “container” object or you can run a function in a particular context.

There are some laws that you must follow. Really you should just make sure that fmapping the identity function (function(x) { return x; }) is equal to just calling the identity function.


  fmap(id) == id;

I guess the last thing I wanted to say was that a List is a functor. fmap in the cast of list is just our beloved map function that runs a normal function on each element inside of the list. So the container analogy works well here too.

Well, that’s all I’ve got for now. Goodnight sweet Tumblr.

Silly module tricks

Sun, 17 Jun 2012 08:47:00 -0700

I’d been jealous of a nice haskell feature, as I typically am, and thought I’d try to get as close as I could with javascript, as I typically do. The “must have” feature is the ability to mix in a module globally or qualify it with a name. Suppose we have an Account module with two functions: sayName and User. Here’s the desired behavior:

I can mix in all the exported functions to the global namespace


import Accounts

introduce :: Name
introduce = sayName user
	where user = User "brian"

Or I can qualify the name so nothing clashes namespacewise.


import qualified Accounts as Accts

introduce :: Accts.Name
introduce = Accts.sayName user
	where user = Accts.User "brian"

Here’s what I came up with in js:

Qualified


require('./account').as('Acct');

var user = Acct.User('brian');
var introduction = Acct.sayName(user);

or unqualified:


require('./account').as();

var user = User('brian');
var introduction = sayName(user);

The account module looks like this:


require("./support/functional");
var installer = require('./support/installer');

var User = function(x) { return {name: x} }

var _getName = pluck('name');

var sayName = compose("'Hi my name is '+", _getName);

installer.exports(module, {User: User, sayName: sayName});

I’m always looking for something cleaner so let me know if you find it!

*EDIT: Here’s installer.js


var exports = function(mod, obj) {
  var GLOBAL = (typeof(window) == 'undefined') ? global : window;
  
  mod.exports = {
    as: function(name) {
      var target;
      
      if(name) {
        target = GLOBAL[name] = {};
      } else {
        target = GLOBAL;
      }
      
      for(k in obj) target[k] = obj[k];
    }
  }
}

module.exports = {exports: exports}

Sweet! They filmed me jabbin’

Sat, 12 May 2012 17:01:00 -0700

Sweet! They filmed me jabbin’

Everybody loves monads

Sat, 12 May 2012 16:07:00 -0700

I made a monad library for javascript. I’m hosting it here https://github.com/DrBoolean/MonadsJs. **This was a monad library based on the one for clojure since we weren’t using types in js. Since then I’ve updated the library to use objects as types so while the examples here still have the same outcome, they don’t work the same way anymore and the api is different. A great way to learn about monads is to watch Bob Martin’s talk. Let’s look at a few built in ones first. I wouldn’t worry about the mechanics so much, but rather the functionality you gain with these puppies.

MaybeM

Here’s the maybeM monad:

	
maybeM = defMonad({
  mResult: id,
  mBind: function(mv, f) {
    return mv ? f(mv) : null;
  }
})

Let’s see what it can do… Let’s pretend we’re in the admin section of some sexy backbone meteor ecommerce app. If we wanted to print the name of a customer attached to a cart we could define a function like this:


var getCustomerName = compose('.name', '.customer', '.order');

// and the calling code:
var cart = { order: { customer: { name : "Bob Jones" } } };
getCustomerName(cart); // "Bob Jones"

Yes yes, demeter wept, I know. But every once and a while you need a function like this. But what if there is no customer attached yet. Or order even?

	
var cart = { };
getCustomerName(cart); // TypeError: Cannot read property 'customer' of undefined

We’d have to do some crazy crap like this:


var getCustomerName = function(cart) {
  if(cart.order && cart.order.customer) return cart.order.customer.name;
}

Yuck! MaybeM to the rescue!

	
var getCustomerName = compose(liftM(maybeM, compose('.name','.customer')), '.order');

// calling...
var cart = { };
getCustomerName(cart); // null

What we’ve done is made a new function on the fly with liftM(maybeM, compose(‘.name’,’.customer’)) in the middle of our compose chain. The function will not run if order is null! “Look ma, no null checks”. So if we don’t care about the result we say it’s maybe there. In technical terms, we’ve attached a context to our value (attached a maybe context to our cart) and we “lifted” our function to work with that kind of value. We could have used the alternate monad syntax of:


var getCustomerName = maybeM(function(cart){
  order <- cart.order
  return order.customer.name;
});

Same deal. What’s cool is you can do a liftM(maybeM, myFragileFunction) where ever you want. You can define a function like that or use it when you’re calling it. That makes working with null easy. Let’s look at a different example.

ListM

	
listM = defMonad({
  mResult: function(x){
    return [x];
  },
  mBind: function(mv, f) { 
    return flatten(map(f, mv));
  }
});

The list monad is a little funky to use at first, but it is crazy useful. It’s just maps inside of maps. Keeping with our ecomm example, we’d like to display a dropdown of all the variations of each shirt and size. Let’s do that the hideous way first.

	
var shirts = ['"Mr. Bean" Shirt', '"I do what the voices in my head tell me" Shirt'];
var sizes = ["SM", "LG", "XL", "XXL"];

var makeOptions = function(){
  var result = [];
  for(var x=0;x

Calling it, we get something like:

	
[ '"Mr. Bean" ShirtSM',
  '"Mr. Bean" ShirtLG',
  '"Mr. Bean" ShirtXL',
  '"Mr. Bean" ShirtXXL',
  '"I do what the voices in my head tell me" ShirtSM',
  '"I do what the voices in my head tell me" ShirtLG',
  '"I do what the voices in my head tell me" ShirtXL',
  '"I do what the voices in my head tell me" ShirtXXL' ]

Let’s do it the sexy way:

	
var makeOptions = liftM(listM, "+");

makeOptions(shirts, sizes);

Wow, right?! Let’s take a moment to imagine the horror of adding colors in the first example. In our monadic one, nothing changes. We just call it with a third list:

	
var colors = ["red", "blue", "green", "yellow"];

makeOptions(shirts, sizes, colors);

Bitchin. You may decide to use that to create a list of every permutation and sort it to find the best options. You may also use it like this next example. Our ecomm site is in dire need of some stats because stats are fun to program. We want what products were purchased from a given set of users.


var users = [{orders: [{items: [{name: "product A"}, {name: "product B"}]}]}, {orders: [{items: [{name: "product C"}]}]}];

var getStats = listM(function(users) {
  u <- users
  o <- u.orders
  i <- o.items
  return i.name;
});

getStats(users); // [ 'product A', 'product B', 'product C' ]

It may be hard to see from my contrived example, but each line is it’s own map inside the line above that’s map. If you’re familiar with list comprehensions it works just like that. Let’s write that out by hand just to see.

	
var getStats = function(users) {
  return map(function(u){
    map(function(o){
      map(function(i) {
        return i.name;
      }, o.items);
    }, u.orders);
  }, users);
}

Now that we’ve seen some built in ones. Let’s see how to make a monad.

DotM

If we have our data type “dots” and we want to work with them as if they were numbers we can can define a dot monad

	
dotM = defMonad({
  mResult: compose(join(""), repeat(".")),
  mBind: function(d, f)  {
    return f(d.length);
  }
});

The monad has two functions mResult and mBind. The mResult is first so let’s talk about that first.


compose(join(""), repeat("."))

The repeat function usually takes two arguments: the thing to repeat and a number of times to repeat it. Here it is being partially applied with “.” so it’s just waiting for it’s number and it will return an array of .’s After that, we join the array and get a string of dots. Easy breezy. For the the mBind we make a function that first takes it’s dots, then it’s function and calls the function on the length of the dots. That effectively converts the dots into numbers for our function to use. So let’s see it in action.

	

var divideDots = dotM(function(da, db) {
  a <- da
  b <- db
  return a / b;
});

divideDots("....", "..");  // 2

The left arrow kind of “pulls” the number value out of the dot value. Then we just divide knowing that a and b are just numbers. You can also “lift” a normal function that doesn’t take dots into the dot monad. So divide works like a normal function, but we lift it and viola! Divides dots.

	
var divide = function(a,b) {
  return a / b;
}

var divideDots = liftM(dotM, divide);

divideDots("....", "..");  // 2

Partial Application

Sat, 12 May 2012 16:06:00 -0700

My dad once told me there are some things in this world that you can live without…until you get them. This is a truism that gets truer for me every year. I think it has something to do with better technology. Take for instance, an iphone or spotify or streaming netflix. In my dad’s case he was talking about a microwave. Generation gap! Anyways, partial application is one of those things. I certainly use it more than my microwave, and i microwave tons of junk, daily. So what is it? Well, it’s exactly how it sounds: Applying a function partially. Partially in terms of arguments. If have a function that takes, say 3 arguments, we can give it 1 or 2 and get back a new function that only takes it’s remaining arguments. Kind of like “preloading” it with a few or all of it’s arguments. Let’s take a looksee.

var sumOfThree = function(a,b,c) {
  return a + b + c;
};

var needsTwoMoreArgs = sumOfThree.partial(20);
var justNeedsOneMore = needsTwoMoreArgs.partial(30);
justNeedsOneMore(10); // 60

Here, there’s a function sumOfThree that will take 3 arguments and add them together. We begin by giving it it’s first argument, which will return a brand new function that we’ve name needsTwoMoreArgs. Indeed, it does only need two args to complete the call. needsTwoMoreArgs has stored it’s first argument 20 and can’t wait to get the others. Here’s a conceptual representation of that:

function(b,c) {
  return 20 + b + c;
};

So next we partially apply it yet again with 30 and name the resulting function justNeedsOneMore. We call justNeedsOneMore with 10 and finally get a result! We can apply as many as a time as we like:

// two at a time
var justNeedsOneMore = sumOfThree.partial(20, 30);
justNeedsOneMore(10); // 60

// or all three!
var doesntNeedAnyArgs = sumOfThree.partial(20, 30, 10);
doesntNeedAnyArgs(); // 60

Wicked awesome. One thing to note before we go any further. The partial function is not built into vanilla javascript. We’re using osteel’s lib to grab this behavior. Something else you can do is give it an underscore as a placeholder.

var makeBobsName = sumOfThree.partial("Bob", _, "Smith");
makeBobsName("M."); // Bob M. Smith

Currying

Currying is a technique where you return a new function for each argument that’s called - in effect partially applying it each time. So if we have a curried function we don’t have to explicitly call partial each time. In haskell, each function is defaulted to this behavior. I’ve made a little wrapper defn that will do that for your functions as well. It lives in my fork of osteele’s lib https://github.com/DrBoolean/Functional-Javascripts. Let’s play with that!

var sumOfThree = defn(function(a,b,c) {
  return a + b + c;
});

var justNeedsOne = sumOfThree("hell", "o ");
justNeedsOne("world"); // hello world

map(sumOfThree(1,2), [3,4,5,6]);  // [ 6, 7, 8, 9 ]

var sum = reduce("+", 0);
sum([1,2,3,4]); // 10

var getVowels = filter(match(/[aeiou]/ig));
getVowels("so many vowels!"); // [ 'o', 'a', 'o', 'e' ]

The last example is particularly cool. It partially applies match and filter. We’ve done 2 things to be able to write code like this. The first was to make a function called match that takes it’s regular expression first and it’s string second. Then we wrapped in a defn.

match = defn(function(expr, x) { return x.match(expr); });

The string as the second argument allows us to partially apply it without knowing what the data that we’re operating on will be. We’re effectively Separating our data from our functions. That makes for really generic code since we have general functions waiting for whatever data they get rather than first have the data and calling functions on it. It’s no coincidence that the map, filter, and reduce functions take their data second either. This wrapping of native functions isn’t really hard to do. It’s pretty much the same thing each time. I’ve pretty much wrapped all the native functions i normally use (there really wasn’t all that much) and put them on my github in a lib called the prelude. Now we can code like the wild animals we are! But really, I haven’t had any performance issues or namespace collisions so far. We can take it one step further and split them out to mix in appropriately when needed or even pass some argument to qualify the names, but for now, I’m building production apps daily without worry so if it ain’t broke… In the end, partial application is okay on it’s own, but really shines when using together with compose. This can help you fix up arguments so functions compose better…or at all. When we start matching those two up together we get a powerful combination that proves more useful than a microwave.

Tweet Grammer Fixer: OO vs FP

Sat, 12 May 2012 15:44:00 -0700

To play with what I’ve been learning, I’m going to make a OO vs Functional comparison. The goal is to clean up tweet grammer. The output should be something like:

// Before
// "I'm tweeting like an animal but I keep missing punctuation. someone make me a tool.Then I can tweet like a scholar."
// After
// "I'm tweeting like an animal, but I keep missing punctuation. Someone make me a tool. Then I can tweet like a scholar."

Object Oriented	Functional
var GrammerChecker = function(tweets) { this.tweets = tweets; } GrammerChecker.prototype = { check: function() { return this.tweets.map(function(t){ var clean_tweet = new CleanTweet(t); return clean_tweet.clean(); }); } } var CleanTweet = function(tweet) { this.tweet = tweet; } CleanTweet.prototype = { clean: function() { this.commaBeforeBut(); this.capitolAfterPeriod(); this.spaceAfterPeriod(); return this.tweet; }, capitolAfterPeriod: function() { this.tweet.replace(/\.\s+([a-z])/g, function(word){ return word.toUpperCase(); }); }, spaceAfterPeriod: function() { this.tweet.replace(/(\w)\.(\w)/g, "$1. $2"); }, commaBeforeBut: function() { this.tweet.replace(/(\w+)[^,]but/gi, "$1, but"); } } module.exports = GrammerChecker;	commaBeforeBut = replace(/(\w+)[^,]but/gi, "$1, but"); capitolAfterPeriod = replace(/\.\s+([a-z])/g, '.toUpperCase()'.lambda()); spaceAfterPeriod = replace(/(\w)\.(\w)/g, "$1. $2"); check = map(compose(spaceAfterPeriod, capitolAfterPeriod, commaBeforeBut)); module.exports = {check: check};

Object Oriented

Functional

var GrammerChecker = function(tweets) {
  this.tweets = tweets;
}

GrammerChecker.prototype = {
  check: function() {
    return this.tweets.map(function(t){
      var clean_tweet = new CleanTweet(t);
      return clean_tweet.clean();
    });
  }
}


var CleanTweet = function(tweet) {
  this.tweet = tweet;
}

CleanTweet.prototype = {
  clean: function() {
    this.commaBeforeBut();
    this.capitolAfterPeriod();
    this.spaceAfterPeriod();
    return this.tweet;
  },
  
  capitolAfterPeriod: function() {
    this.tweet.replace(/\.\s+([a-z])/g, function(word){ return word.toUpperCase(); });
  },
  
  spaceAfterPeriod: function() {
    this.tweet.replace(/(\w)\.(\w)/g, "$1. $2");
  },
  
  commaBeforeBut: function() {
    this.tweet.replace(/(\w+)[^,]but/gi, "$1, but");
  }
}

module.exports = GrammerChecker;

commaBeforeBut = replace(/(\w+)[^,]but/gi, "$1, but");

capitolAfterPeriod = replace(/\.\s+([a-z])/g, '.toUpperCase()'.lambda());

spaceAfterPeriod = replace(/(\w)\.(\w)/g, "$1. $2");

check = map(compose(spaceAfterPeriod, capitolAfterPeriod, commaBeforeBut));

module.exports = {check: check};

And here’s using it:

Object Oriented	Functional
var requester = require("../requester1"); var GrammerChecker = require("./grammer_check_oo"); requester.get("http://search.twitter.com/search.json", {q: "food"}, function(response){ var json = JSON.parse(response); var tweets = json.results.map(function(r){ return r.text; }); var checker = new GrammerChecker(tweets); var result = checker.check(); console.log(result); });	require('../functional'); var requester = require("../requester"); var GrammerCheck = require("./grammer_check_fun"); transform = compose(map('.text'), '.results', JSON.parse); getTweets = requester.get("http://search.twitter.com/search.json", {q: "food"}); getTweets(compose(log, GrammerCheck.check, transform));

Object Oriented

Functional

var requester = require("../requester1");
var GrammerChecker = require("./grammer_check_oo");


requester.get("http://search.twitter.com/search.json", {q: "food"}, function(response){
  var json = JSON.parse(response);
  var tweets = json.results.map(function(r){ return r.text; });
  var checker = new GrammerChecker(tweets);
  var result = checker.check();
  console.log(result);
});

require('../functional');
var requester = require("../requester");
var GrammerCheck = require("./grammer_check_fun");

transform = compose(map('.text'), '.results', JSON.parse);
getTweets = requester.get("http://search.twitter.com/search.json", {q: "food"});
getTweets(compose(log, GrammerCheck.check, transform));

To get this haskelly in javascript, I’m using osteele’s functional.js and a few function wrappers of my own. The functional version of replace auto-currys and doesn’t destroy the original string. The helper libraries are Here

What i noticed

After writing the example, I realized that the OO version wasn’t very resuable due to my nomenclature. If I rename “tweet” to “sentence”, i get a little library out of it. I often try to rename things afterwards. This plays a large part in cleaning up my code - generalize and extract everything possible into a lib, then implement with specific verbage in the app. But for the functional side, due to pointfree style, I don’t need to name anything anyways! Done. In fact, the functional side looks more like a libary than app code. It’s natural to write this way. We could extend it pretty easily into functions that make dsl-like grammer checker.

commaBefore = function(word) {
  return replace(new RegExp('(\\w+)[^,]'+word, 'gi'), "$1, "+word);
}

Now we can do things like this:

Object Oriented	Functional
// chaining by returning 'this' var checker = new GrammerChecker(tweets); checker.commaBefore("but").commaBefore("however").commaBefore("yet").result;	map(compose(commaBefore("but"), commaBefore("yet"), commaBefore("however")));

Object Oriented

Functional

// chaining by returning 'this'
var checker = new GrammerChecker(tweets);
checker.commaBefore("but").commaBefore("however").commaBefore("yet").result;

map(compose(commaBefore("but"), commaBefore("yet"), commaBefore("however")));

But then when I want to say, compose the GrammerChecker with a HtmlEntities sanitizer so I can switch stuff like &quote; to “, the result would probably be as follows:

Object Oriented	Functional
var checker = new GrammerChecker(tweets); var cleaned_grammer = checker.commaBeforeBut("but").commaBefore("however").commaBefore("yet").result; cleaned_grammer.map(function(cg){ var entities = new HtmlEntities(cg); return entities.santize(); });	var check = compose(commaBefore("but"), commaBefore("yet"), commaBefore("however")); var getResult = map(compose(HtmlEntities.santize, check)); getResult(tweets);

Object Oriented

Functional

var checker = new GrammerChecker(tweets);
var cleaned_grammer = checker.commaBeforeBut("but").commaBefore("however").commaBefore("yet").result;
cleaned_grammer.map(function(cg){
	var entities = new HtmlEntities(cg);
	return entities.santize();
});

var check = compose(commaBefore("but"), commaBefore("yet"), commaBefore("however"));
var getResult = map(compose(HtmlEntities.santize, check));
getResult(tweets);

For OO, I have to create a new object, put the data in it so i can do stuff to that data, then do that stuff. In FP, since we can compose functions or even programs together, we can just glue them both together and pipe our data through it.

So who wins?

Which is better? I’ll leave that to the reader to decide, but I do have some things to note.

Functional is a fraction of the size of code. Distilled to just parts that matter. OO requires a lot more ceremony to get started.
OO would be tricky to make parellel due to imperative instruction and destructive methods.
OO is rather black boxy during usage. You see the tweets go in to the GrammerChecker, but don’t know what’s going on from there. Then the check() method returns a result, which are hopefully the cleaned tweets, but it’s not that obvious (probably my fault). This may seem kind of trivial here, but i think it’s a huge deal when working with more complex examples. With Functional, you know the check function can only take an argument and return a result (as all functions in the paradigm do) and there’s only 1 function call (no constructor) so it’s pretty easy to see where the tweets go.

Composition

Sat, 12 May 2012 11:55:00 -0700

Composition is a fancy name for passing the result of one function as an argument into the next function. If we have some functions like these:


add2 = function(number) {
  return number + 2;
}

subtract1 = function(number) {
  return number - 1;
}

We could do this:


addSubtract = function(n) {
  var addedValue = add2(n);
  return subtract1(addedValue);
}

Or We could do this:


addSubtract = compose(subtract1, add2);

Both would yield 4:


addSubtract(3);  // 4

compose makes a brand new function. The data flows from right to left applying each function along the way. Right to left makes sense when you think about the parenthesis going to the right of the newly constructed function. Here’s another few examples


dasherize = compose(join('-'), split(/\s+/g);
dasherize("Big Al's Trucks"); // "Big-Al's-Trucks"

doFunkyThingsWithName = compose('.toUpperCase()', reverse, '.name')
doFunkyThingsWithName({name: "George"}); // "EGROEG"

The combination possibilities are endless. We can compose groups of functions that go together into little programs. Then we can even compose those programs! Checkout how easy it is to play around:


var loggingFun = compose(log, subtract1, log, add2);
loggingFun(3);
// 5
// 4
// 4

var memoizedFun = memoize(loggingFun);
memoizedFun(4);
// 6
// 5
// 5

memoizedFun(4);
// 5

var newProgram = compose(otherProgram, memoizedFun);

parallel_compose(thirdProgram, newProgram);

Why is this so amazing?

No data

You may notice I don’t need to name any intermediate results. This is a big deal. This assists in separating your data from your functions since you simply don’t see the data. I think a lot of people are turned off from functional programming by the thought of juggling arguments (data) around all the time instead of tucking them away in a nice object. Here, there is no data at all, rather functions plugged together to work on anything. This gives you megagenericicity which is a word i just made up. Starting from the original data call, we just start composing away.


UsersController = (function(){
  index = db.all('users', compose(renderView, manipulateUserData));

  return {index: index}
})();

Build up from smaller functions

Is it a surprise to find out most of what you write is the same stuff over and over again? Instead of writing out the same function calls with different names or the same assignment statements to different variables, you can skip all of that and just drop the function name in. The code drops in size, becomes more generic, and you distill the code to just the important behavior. If you’re worried about names missing since names give you an idea of what we’re operating on, don’t sweat it - just assign a specific name to each function:


// no one says it has to be like this:
getArgNames = compose(last, match(/\((.*)\)/), first, split('\n'));

// it can easily be like this:
firstLine = compose(first, split('\n'));
contentInsideParenthesis = compose(last, match(/\((.*)\)/));
getArgNames = compose(contentInsideParenthesis, firstLine);

Smaller functions that do one thing means more reusable parts. Taking advantage of the divide and conquer strategy, we can build very complex systems with easy to grok simple functions. Turns out, lots of the smaller functions you break out can be put in to utility libraries and moved out of your application code. This technique promotes reusability (common theme here…) and makes your app simpler.

Declarative Programming

In declarative programming, we tell the computer what to do and let it accomplish the task however it sees fit. Think of SQL. You express a query as a single expression and let the computer do it’s job. The SQL folks can make the compiler better and better and you don’t have to change a single line. Imperative, order of execution style programming has a funny way of hindering that freedom. Like doing our own garbage collection in code, when we hard code these low level steps, we steal responsibility away from the compiler/interpreter and place it in our application. Also, one expression can be manipulated much easier than several lines of separate steps: you simply copy and paste little chunks of code around. Want logging? Add an extra function in the chain. etc. When we program like this, our application code likely won’t need to change when we optimize. We can fix bugs in our underlying functions, but the statement of what needs to happend doesn’t change. Ladies and gentlemen, we’ve risen to a higher level.

Free Dsl

Don’t actually do anything! Just say it and let the other stuff do the work. Brilliant.