Functional Ruby

Functional Programming through the Ruby veneer

Applicative Validation - or - Rails Validation Considered Weird

Hey everyone - this latest post comes from esteemed friend Chris Wilson. He has a big ol’ brain and writes about all sorts of fancy thoughts. Check him out! I hope he’ll grace our pages again, but until then, enjoy this fine piece about applying FP (arguably Haskell) style validation approaches to your once humble Rails applications.

Thanks Chris!

So the way that validation works in Rails has always seemed a bit weird to me. And as I learn more and more about functional programming the weirdness has become clearer. When doing validation in a rails app the flow is something like this:

emp = Employee.create(firstname: Bob)
emp.valid? # => false

# ugh, why not?

emp.errors # => {:lastname=>["can't be blank"]}

emp.lastname = "Boberson"
emp.valid? # => true

So it goes. What is weird about this whole situation is that the information about the validity of the model has been taken out of the return value of methods like “create.” In a way, I prefer the C-ish way of doing things where there’s a success/failure return value, even if it is often embedded in another value. Take “getc” from stdlib:

int getc(FILE *stream)

Getc is a simple function that just returns a single character from some file. What you may wonder is why is the return value “int” rather than “char”? After all, characters can only ever take on values from 0 to 255. The answer is that getc has error reporting built in. If there’s any problem reading a char, getc returns -1. Negative one can never be a valid character and so we know an error happened. Really snarky readers will also point out that C sets “errno” to indicate what the error was, but hey we’re improving. There’s still a slight hack here, we take advantage of the fact that chars and negative ints are disjoint in C. You’ll never have a negative char. But even with the hack, we’re improving. We have the right idea, it just needs massaging.

Back to Rails-land. What if we could return two pieces of information every time we tried to create an active record model? The first could be the newly-created record (if it validated) and the second any errors that were encountered (if it didn’t validate). That would be cool, but wouldn’t we clutter-up the API with junk that’s only relevant sometimes (the would-be error messages)? And think about disjointness again, if the creation worked there will be no error messages and if it failed there will only be error messages. If our validation function returned a 2-element array of value/errors it would look like this:

[<value>, <errors>]  # only one "side" will ever be used at a time

Errors and successfully-created objects are totally separate. Can’t we take advantage of this? The answer is “yes”, as it turns out.

Functional programming has a great solution to this, use a disjoint union type for return. I know of this type as an “Either”, as in it is either a correct value or there’s been some kind of error. This is the gist of how it works:

first = validate_first_name("Bob")
first # => Right("Bob")

but if something went wrong:

first = validate_first_name("Dollar $teve")
first # => Left("illegal character")

The cool thing about this is that the contents of the Either type can be concatenated. In any custom validation function we can do:

def validate_first_name firstname
  firstname == "The Dude" ?
    Left("We want go-getters not abiders") :

def validate_last_name lastname
  lastname == "Lebowski" ?
    Left("No way") :

The way to use this is to build up a result value that’s either the arguments to the Employee constructor or it is the errors that prevented us from doing that.

I’m going to use the Rumonade library from here on. This is still somewhat of a tough fit with how Rails works, but I want to give a sketch of what could be done.

The first thing is to run all the validations on our inputs:

result = validate_first_name(params[:firstname]).lift_to_a +

At this point result will either contain a Right array of the validated arguments or a Left array of the errors we encountered. Being optimistic, we can put code like this in the controller:

if result.right?
  result.right.bind do |args|
    Employee.create *args
  result.left.bind do |errors|
    # handle errors

It is perhaps a little clunky, but I think that a quick refactor would clean this up a bit.

def apply value, &blk
  value.right? ?
    value.right.bind(blk) :

Apply does a little case analysis for us and provides a sort of pass-through for the given block if the validation was successful. Then the above controller code can become this:

unless apply(result){|args| Employee.create *args}
  result.left.bind do |e|
    puts "Errors: #{e.join(', ')}"

If it still looks clunky, just think of the extra stuff that it is doing for you. It creates the Employee object if all the validations were run successfully and then it lets you decide what to do if there were errors. This is all with no sleight of hand or furtive fiddling with global state. Everything this code is doing is right in front of you. Another cool thing is that the validations are easy to extend. If you want to add another there is just one place that must be modified.

result = validate_first_name(params[:firstname]).lift_to_a +
         validate_last_name(params[:lastname]).lift_to_a +
         validate_full_name(params[:firstname], params[:lastname]).lift_to_a

And so on. All the machinery of combining and handling errors vs. values has been abstracted out.

I don’t know if rails will ever go with something like this, or if it is even a good fit, but I do know that I’ve run into problems traditional error-handling system. I think part of the pain I felt was due to its relative opacity.

The benefits of bringing validation “in-band”, into the return values of the validators, is a great improvement in clarity. There is also a lot of flexibility to be gained here. Validations are whatever you say they are, there’s no errors.add(:attribute, ...) to worry about.

I hope you’ve enjoyed my little excursion into validation. For more info on this, indeed it’s what I drew on heavily to write this, check out:

Monadic Design Patterns for the Web

So I’ve decided that in order to be the best Functional Rubyist one can be, we can’t solely focus on the Ruby community. There are some great things happening in that space to be sure, but we’re really just playing catch up with everyone instead of innovating (which is fine, we need a steady foundation first!).

That said, I’ll still try to predominantly keep things relevant. Feel free to scorn me in via email or in the comments if you find this upsetting ;)

While it’s nothing new, and really truly has very little to do with Ruby, I must say that Gregory Meredith’s C9 lectures on web development with Monads are definitely some of the finer explorations of the subject. So after recommending them to people time and time again when they are having a hard time grokking Monads or can’t see how they’d apply these patterns to their daily lives, I’ll just come out in one canonical spot and heartily recommend that you all watch the series. At the very least you deserve to watch the introduction for it’s clear exposition.

Part One

Part Two

Part Three

Part Four

Mr. Meredith was also working on a book about this very subject (marketed toward the Scala crowd, I’m guessing at the publisher’s wishes), which unfortunately has been dropped by Apress. Pretty sad about this, but let’s hope it will see the day of light in some capacity, some day.

Also, just to keep things slightly about Ruby here, you’ve read Dave Fayram’s Rubyists Already Use Monadic Patterns right? Of course you have.

Lambda Calculus Made Easy

Oh, Lambda Calculus. The often touted ancestor of Lisp. The underpinning of most Functional languages. Two words to bust out at a dinner party in a vain attempt to sound smart in front of your fellow programmers 1.

At it’s most basic, Lambda Calculus states that all computations can be expressed in terms of two things: Functions and Function Application. In Ruby parlance these would be lambda { |x| x } expressions and Proc#call. That’s it 2. You’ve now expressed a Turing Complete language. Numerals? Yep. Arithmetic? You bet!.

So… neat.

While one can read in many places on the web as to what the Lambda Calculus is, as well as find ample implementations of it (usually in Lisps, no less), it can often all seem a bit magical and esoteric until one encounters it in a more familiar context 3.

Basically, this has all been posturing to set you up for Tom Stuart’s excellent Programming With Nothing, which does a much finer job of breaking all of this down than I could ever hope to, all in our beloved Ruby. If you have any interest at all, do yourself a favor and read the blog post, watch the video, and (attempt to) grok the code. It really solidifies that one is capable of most any computing operation after watching Tom implement fizzbuzz 4 with the tiniest subset of Ruby.

Surely one could write more on the subject, and perhaps in the future I’ll even produce some original content (how shocking!), but until then, I’ve hopefully at least pointed you to some of the excellent pre-existing resources on the topic.

ps: Maruku supports footnotes! I adore footnotes. If you don’t and I’ve beaten them to death in this article, please let me know. Until then, footnotes will continue to be abused.

  1. One of two things tend to happen here, eyes will glaze over, or someone that knows more about it than you will dispel any wonder you once commanded.

  2. It’s even less clumsy in languages that don’t have a special case for function application. Scheme, Python, and even JavaScript. Yehuda Katz has written about Ruby Callables a handful of times and has some reasoned thoughts on it.

  3. If for some reason you find yourself more JavaScript inclined, or are just so deeply into the subject that you’d like more, you could do worse than read Matt Might’s Church encodings, the U combinator and the Y combinator in JavaScript.

  4. Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.

Hamster: Immutable Data Structures for Ruby

Ruby, oh Ruby, so deeply entrenched in mutability one can hardly trust the floor beneath them. Sure, we can have immutability by convention (ie: trust yourself and your team, clearly a foolish thought). Sure, you can kind of address this with calls to Object#freeze. Really though, at the end of the day, wouldn’t it be nice to have a native implementation of immutable data structures in our beloved Ruby? Doubly so, were they performant.

One brave developer out there, Mr. Simon Harris has set out to do just that for us.

Hamster - Efficient, Immutable, Thread-Safe Collection classes for Ruby

Hamster has been under steady development for over 2 years now and provides immutable alternatives to all of Ruby’s built in collection data structures. Hashes, Lists, Sets, Stacks, Tries, Tuples, and Vectors are all there. These are for the most part well documented in Hamster’s readme and spec suite.

Hamster achieves it’s immutability in a fashion similar to Clojure. Any operation that would in a non-functional language mutate the original object, instead will copy that object and return a new one with the updated values in place. While this is achievable with Object#dup, things can get messy quickly, and it certainly doesn’t aid in the readability of your code.

In addition to thread-safety via immutability, we also get the benefit that most operations on Hamster collections are performed lazily so their return values won’t be calculated until necessary. Languages such as Haskell have used this to great effect. In addition to intuitiveness (ie: Why calculate a value that’s unused?), lazy evaluation can sometimes lead to a much clearer expression of certain algorithms.

Is Hamster ready for the prime time? Maybe. Hamster is certainly more mature and documented than some of it’s condtenders. Do check out the readme which does a fine job pointing out potential caveats. It certainly seems worth auditioning for your next project, and since it supports an API pretty similar to native Ruby counterparts, should you have to revert one day I can’t imagine you’d encounter much pain.

If you’re interested in hearing more of what Harris has to says about immutability, you should definitely read Functional Programming in Object Oriented Languages (an excellent blog post in it’s own right).

MenTaLguY on Monads in Ruby

Put yourself back in the year 2005.
Were you pushing the limits of Ruby?
Were you ruminating on Monads?

Oh yeah, me too. ;-p

But in all seriousness, way back then MenTaLguY was doing just that, and in doing so produced some of my favorite posts on Monads as they (could) apply to Ruby development.

Not only did the series help to solidify my understand of the subject, it also gave me ideas on how to use Monadic patterns in my own code.

So to kick off Functional Ruby, why don’t we deep dive into one of the more esoteric (and interesting!) topics in Functional Programming, Monads!

Part 1 introduces us to just what a monad might be. If you don’t even know what a Monad is, start here.

MenTaLguY: Monads in Ruby Part 1

Part 2 walks us through an implementation of the Identity Monad, arguably the simplest of many, and a lightweight explanation of Monadic Laws.

MenTaLguY: Monads in Ruby Part 2

Part 3 discusses Arrays as Monads (which in some circles really is the crux of a monad… sort of) and starts getting useful.

MenTaLguY: Monads in Ruby Part 3

Phew. That may have been a bit much, but why not start with a bang :)

Thanks @mentalguy!

PS: For the holdouts unconvinced of the significance of Monads, other than being a mighty fun subject in and of itself, is that it gives us a common language to talk about a pattern that emerges in our code from time to time, perhaps more often than you realize ;)

Welcome to Functional Ruby

I couldn’t help but notice that the Ruby community (and the programming community at large) was buzzing with excitement over the functional programming paradigm. While there are many people and articles scattered about the net for excellent information on the subject of Ruby’s relationship with Functional Programming, I was surprised to find that no such central repository of all this wonderful content existed.

It is my hope that Functional Ruby will become that repository. I’m not sure which format would best house this content, perhaps a wiki would be better, or perhaps it would just be supplementary. However, for a first stab, let’s see how a content aggregator (with occasional original content) works out.

While I have many excellent things to share with you lined up, should you come across anything you feel shares the spirit of this site, by all means email me at or tweet at @FunctionalRuby.

I’ve not done this before and am certainly open to feedback, so don’t hesitate to give it.

Robert (@rbxbx)