Disfunctional

Monads as I understand them

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

//+ 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);

//+ 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);

Getting more robust

//+ 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);

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);

So monads are functors that flatten?

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

//+ 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)

Lastly, …for now

//+ 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)

Tail call optimization on it’s way… Who gives a frak?!

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

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

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

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]

Okay, on with the show

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

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

A better way

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

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

But wait, there’s more

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

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

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

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

A vulgar display of explicit iteration

I do declare

Brian vs Abstraction Round 1

Brian vs Abstraction Round 2

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

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

//+ 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);

Showing off

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

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

var results = [];

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

runReport(results);

map_p(chargeCard, runReport, credit_cards);

People say I’m just a dreamer…

Functor, I hardly knew her!

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);

So what’s up with Functors?

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

var o_name = Observable("brian");

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};
}

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

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

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"

In conclusion

  fmap(id) == id;

Silly module tricks

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"

import qualified Accounts as Accts

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

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

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

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

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

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});

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}

Everybody loves monads

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

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

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

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

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

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

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

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

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

ListM

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

	
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

	
[ '"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' ]

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

makeOptions(shirts, sizes);

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

makeOptions(shirts, sizes, colors);

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' ]

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

DotM

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

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

	

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

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

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

var divideDots = liftM(dotM, divide);

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

Partial Application

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

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

// 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

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

Currying

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' ]

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

Tweet Grammer Fixer: OO vs FP

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."

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};

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));

What i noticed

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

// 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")));

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);

So who wins?

• 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

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;
}

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

addSubtract = compose(subtract1, add2);

addSubtract(3);  // 4

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

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

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);

No data

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

  return {index: index}
})();

Build up from smaller functions

// 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);

Declarative Programming

Free Dsl