moonmaster9000

Guess what? Haskell function definitions HAVE to be grouped together.  I’d always just assumed it was convention (a convention that in most cases enhances readability), but it turns out it’s a requirement of the language. What do I mean? Consider the following:

Notice that I grouped all of the pattern matches for “sayHello” together in sequence, then plowed through all the pattern matches for “sayGoodBye”. Most of the time, that’s exactly what you want. However, consider the alternate grouping: 

In this case, I grouped by what I was matching against, not by function. Both ways of grouping have their place, however, I was a little shocked to learn that haskell does not allow the second method. I googled around for a bit, assuming that there was at least a language extension that would relax this restriction, but came up with nothing. I jumped on the Haskell IRC; not only did no one know of a language extension that would allow this, one haskeller even exclaimed that it would be impossible to implement!

Well, for my haskell web-dev DSL “bird”, I’ve implemented it (kinda). You can at least organize your get/post/put/delete functions however you see fit. The following is valid bird haskell, and the “bird nest” command will regroup your get/post/put/delete functions so the GHC compiler won’t complain:

It will probably be another couple of years before I know enough haskell to attempt to write a GHC language extension, but perhaps I could generalize my algorithm and build a ghc preprocessor…. 

I’ve recently been developing my own sinatra-inspired web framework in Haskell called bird. And though I haven’t exactly accomplished a lot with it (our newborn has somewhat limited the amount of time I have for recreational programming), the endeavor has helped me learn the language. 

I’ll compare and contrast a simple web app that responds to a url /echo/:s. If s is a 4 letter word, it should return a 403 Forbidden. Otherwise, it should echo s. 

The two newest and most popular haskell web frameworks are Snap and Yesod. Both of these frameworks are chocked full of useful features that I haven’t even begun to implement in bird, and both of these frameworks have sites full of lots of great documentation. Let’s see the Snap version:

Wow. Um, that’s quite a lot of (gnarly) code to accomplish such a simple task. Is all of that really necessary (hint: no). I actually didn’t have to write the entire “main” function; most of it was generated. But to add the routes, I was forced to edit the middle of the generated function. Yuck. That’s just wrong.

Next up, Yesod:

Yesod is a very cool project, with some very promising uses of template haskell (read: macros) and quasi-quoting (two language features I’m just beginning to grok). This code is definitely much more succinct than the Snap version, and much more palatable to my tastes, yet could there perhaps be an even more succinct way to create this tiny web app? Enter bird:

That’s it. You don’t need to write another single line of code. The framework takes care of all the details for you, leaving you free to focus on your actual application logic. It also lets you use Haskell’s built in pattern matching facilities for routes, instead of reinventing it with route handlers that capture patterns in strings like “/echo/:s” or “/echo/#String”. Of course, bird is more like a hatchling at this point, still learning how to fly, so for any real web app, you’re much better off using Yesod, Snap, or Loli (a brilliant web framework also inspired by sinatra).

Conclusion: Haskell is one of the most exciting languages out there, chocked full of amazingly audacious ideas, and brimming with the potential to revolutionize parallel and concurrent programming. However, if you took a look at the community, I’m fairly certain you’d find it filled with about 96% academia and 4% practicing software engineers. It’s time for Haskellers to focus on crafting usable libraries (that means good documentation and elegant APIs), and it’s time for practicing software engineers to start experimenting with the language. Yesod and Snap have definitely raised the bar for creating thorough, usable documentation…

Pipes in bash rock. It’s a beautiful, simple, powerful concept. The rest of the Bash scripting language, is, of course, complete dog shit. But the pipes; oh yes, the pipes.

Turns out you can do something similar in haskell. It’s already built in, just in reverse: the “$” operator. Check out my contrived, over-complicated factorial method:

The “fac” method computes the factorial of “n” by taking the numbers “1” to “n” out of the infinite list [1..], then folding the multiplication operator (or “injecting” for all the rubyists reading this out there) over the list.

The downside to the “$” operator is that you have to read it right to left. But guess what? Creating our own operator in haskell is trivial:

I can’t actually use a pipe character since that’s already reserved in Haskell.

Now, rewriting our fac method with “==>”:

Gold!

Continuing my series of posts comparing and contrasting the dynamically-typed imperative language Ruby with the strongly-typed declarative language Haskell, I’ll now examine the abilities of these languages to create mutually recursive data structures.

I’d like to model a real-world relationship for the purposes of this post: the relationship between authors and books. An author may write many books, and a single book may be written by multiple authors:

In imperative languages, we implicitly or explicitly rely on pointers to model this type of relationship. Ruby, thankfully, makes pointers implicit:

With this definition, we can now create a cyclical relation thusly:

What I appreciate most about this is how simple and intuitive it is to cyclically relate data in Ruby, abstracting all the gnarly pointer manipulation to the interpreter.

Declarative languages like Haskell, on the other hand, tend to stray pretty far from the underlying hardware implementations. Thus, there is no concept of a pointer (implicitly or explicitly). Instead, we rely on lazy evaluation to make cyclical relationships possible:

Notice that our two “constructor” functions, “createAuthor” and “createBook”, are recursively defined. In a strictly-evaluated language, this would lead to an infinite loop; however, Haskell’s lazy evaluation saves the day, only constructing as much of the author or book in question as our needs dictate.

With these data and function definitions, we can now create an author and book relationship in one line:

But what about retrieving the data in the two languages? For example, given an author “clarke”, how can we retrieve a list of all the titles of books the author has written? In ruby:

Simple enough. In haskell, the process is actually quite similar:

Essentially, the output of the function call “books clarke” becomes the input to the partially applied (“curried”) function “map title”.

What about updating the data? This is where it gets a little more complicated. In Ruby, we’ve already seen that adding an author to a book, or a book to an author, is trivial (we simply use the “«” method on Arrays to objects to our relational collections). In Haskell, however, we’ll need to create our own accessor functions:

Now we can add relational data to an existing author or book like so:

Consistency

Our Haskell implementation suffers from a lack of consistency. Consider the following:

Clearly, we have a problem. I’d love to hear what a real Haskeller thinks about this (it’s quite likely that my haskell noobishness is entirely to blame), yet my guess is that it would make more sense in the end to model Authors and Books and their relationships separately, instead of trying to tie it all into the mutually recursive Author/Book data types I defined. For example, we might have a simple Author type, and a simple Book type, and then create a “Bibliography” data type for listing all the books an author has written (it could consist of a tuple like “(Author, [Book])”). We might also create a “Catalog” data type that consists of an array like [(Book, [Author])] for maintaining the authors belonging to a book.

Follow Up

Based on the constructive feedback in the comments, I’ve fixed the aforementioned consistency problem by abstracting the relational information to a seperate “Catalog” data structure. Here’s the results:

Notice that methods that operate on a Catalog also return a new catalog, allowing us to chain together events like this:

Though the solution is as yet far from complete, I did at least begin to gain a better grasp of the challenges (and rewards) of attempting to model the real world while working in a purely functional language.

In my last post, I contrasted an algorithm for sorting a list so that it would display column-sorted in an n-column liquid layout. In the case of that stateless algorithm, Haskell clearly wound up looking like the more elegant solution. The Haskell code was readable, “self-documenting”, and concise. The Ruby version was longer, significantly less “self-documenting”, and required work-arounds (.dup) for avoiding in-place array modification. I am, however, freely willing to admit that there is quite likely a perfectly elegant Ruby algorithm for that problem that someone much smarter than me could write.

Anyways, programming in the real world often moves beyond purely algorithmic solutions and into stateful (“impure”) IO interactions - a realm where purely functional languages like Haskell are thought to falter.

So, prompted by the examples in “Real World Haskell” book, I wrote my own simple command line utility for converting a file to Unix-style line endings in both Ruby and Haskell. Lets check out the code comparison:

In ruby:

In Haskell:

Although these conversion scripts are currently single purpose (converting the line endings in a text file), I wanted to at least begin to build them in a more generic way, so that not only could I compare simple IO tasks in the languages, but I could also start to compare the amiability of the languages for basic software engineering. Thus, I developed a generic transformation function in both languages that applied a first-class function (or Proc in Ruby) to an input file and wrote the results to an output file.

One thing to note is that Ruby already had a method on the string class for splitting it on Windows and/or Unix style line endings (String#split). The equivalent method in Haskell, “lines”, only works on Unix style line endings, forcing me to write my own splitLines method. Also, given that I haven’t yet learned regular expressions in Haskell, my splitLines method handles OS-agnostic line ending detection via a case statement (which, actually, is probably a more efficient approach anyways).

Conclusions? I’m actually a bit surprised that the Haskell version isn’t significantly longer or more complicated than the Ruby Version. The Haskell IO Monad, at least for simple stateful situations, works perfectly well. Furthermore, both languages, in their own way, support first-class functions (Haskell purely, Ruby via Proc objects), paving the way for powerful, flexible software engineering. Haskell’s higher-order functions and composition support are actually a really powerful (and elegant) glue for building up complicated programs from simpler, reusable pieces.

However, I still have serious doubts that, in a more complicated IO case, Haskell would fair so well. I’ve peaked at enough large-scale Haskell code to know that at a certain point, the Haskell IO monad breaks down, and that for certain problem domains, Haskell code can start to look like large swaths of (lame) imperative procedural code (via Monads), sprinkled with occasional declarative gems. (Checkout Turbinado, a brilliant, if failed, attempt at developing a Rails-ish MVC framework in Haskell).

I love Ruby. I admit it. We’ve had a hot, steamy love affair for the last two years, and I see no end in sight. But, once, long ago, in a university far far away, I had an intense, one semester fling with another language in an entirely different paradigm: Haskell.

Haskell was different. Up to that point, I’d only dated boring, imperative languages like C++ and Java. Haskell was a breath of fresh air. So clean, so pure, so stateless, so chocked full of new, wild concepts like infinite data structures, lazy evaluation, higher-order functions, pattern matching, currying… and in the end, so utterly impractical. Yet it changed the way I thought about code forever.

Recently, when Ruby wasn’t looking, I’d been sneaking peaks at my old Haskell code, and checking up on the Haskell community, such that it is. I was surprised to find Hackage, a growing collection of real-world libraries. I was even more surprised to find the “Real World Haskell” book, chocked full of practical Haskell applications. It’s enough to make me dare to dream of a n elegant, purely declarative web framework…

Anyways, I’m now openly two-timing Ruby. In order to refresh myself on the Haskell language, I converted my “liquidity” gem to a Haskell module (see my previous post on liquidity, column-sorted liquid layouts, and linear algebra). Here’s the code comparison:

In Ruby:

In Haskell:

I probably would have had an easier time writing the Haskell version had I gone beyond the second chapter of the “Real World Haskell” book before diving straight into the code. At the very least, I wouldn’t have spent so much time writing my own versions of “concat” and “transpose” (though I certainly learned quite a bit in the process). I also probably wouldn’t have fought the ghc compiler trying to get the “ceiling” method to work (the key was adding the unsightly “fromIntegral” type conversion methods, since ceiling is designed to accept a “RealFrac” type). A couple of years of Ruby development have been enough for me to completely forget the pains of dealing with a strongly typed language.

On the whole, however, I’m once again amazed by Haskell’s expressiveness, and though I’m still a rubyist first and foremost, I’m excited to expand my declarative horizons with Haskell and continue reading the “Real World Haskell” book.

Liquid layouts: the practice (among other things) of rendering a single ul/li group (like this):

  <ul>
    <li>1</li>
    <li>2</li>
    <li>3</li>
    <li>4</li>
    <li>5</li>
    <li>6</li>
    <li>7</li>
    <li>8</li>
    <li>9</li>
    <li>10</li>
    <li>11</li>
  </ul>

  
  1   2   3
  4   5   6
  7   8   9
  10  11

  <style type="text/css">
    ul {width: 30%}
    li {width: 33%; text-align: left; float: left}
  </style>

  <ul>
    <li>1</li>
    <li>5</li>
    <li>9</li>
    <li>2</li>
    <li>6</li>
    <li>10</li>
    <li>3</li>
    <li>7</li>
    <li>11</li>
    <li>4</li>
    <li>8</li>
    <li></li>
  </ul>

  1   5   9
  2   6   10
  3   7   11 
  4   8

[1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11]
[1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, nil]
[[1, 2, 3, 4], [5, 6, 7, 8], [9, 10, 11, nil]]
[[1, 5, 9], [2, 6, 10], [3, 7, 11], [4, 8, nil]]
[1, 5, 9, 2, 6, 10, 3, 7, 11, 4, 8, nil]

Stumbling around the rubyverse, I happened across an old article by @jnunemaker (of mongo mapper and twitter gem fame) about class variables and inheritance in Ruby, and realized that though I often use class instance variables (i.e., @ variables in the eigenclass), i rarely use class variables (@@), and that I’d never known about the class variable inheritance gotcha.

After following links to various sources on the topic, I felt that much of the discussion further confused the matter (at least for me). There are truly simple solutions to this problem; however, the solution you choose should vary depending upon whether or not you need mutable or non-mutable class attributes.

The problem with @@ inheritance: it’s all the same object

First, lets look at the problem:

# sh$ irb
  
class Wolf
  @@species = 'canis lupus'
  
  def Wolf.species
    @@species
  end
end
  
puts Wolf.species # ==> "canis lupus"

Great, now we’ve got a class variable that can be accessed in both class methods and instance methods through @@.

class Dog < Wolf
   @@species = 'canis lupus familiaris'
end
  
puts Dog.species # ==> "canis lupus familiaris"

Perfect. Now our Wolf and Dog both have their own unique species value. Or do they?

puts Wolf.species # ==> "canis lupus familiaris"

Uh oh. When we set @@species on Dog, it changed @@species on Wolf. Why? Because class variables are shared across all ancestors of a class. They all point to the exact same object in memory.

If your goal is to have inheritable class-level attributes that don’t point to the same object in memory, and can thus be differentiated for each class ancestor, you have many options.

Non-mutable Class Attributes

The first, and simplest option, applies if your attribute is really something that shouldn’t be mutable. For example, a Dog’s species is “canis lupus familiaris”, and it will always be “canis lupus familiaris”, and if we were actually designing some kind of OO library that encapsulated the behavior and properties of a Dog, we probably wouldn’t want to allow people using the library to change the value of the dog’s species.

In that case, you don’t even need a class variable. A simple constant will do:

# sh$ irb
  
class Wolf
  SPECIES = "canis lupus"
end
  
puts Wolf::SPECIES # ==> "canis lupus"
  
class Dog < Wolf
end
  
puts Wolf::SPECIES # ==> "canis lupus"  
puts Dog::SPECIES # ==> "canis lupus"
  
class Dog
  SPECIES = "canis lupus familiaris"
end
  
puts Wolf::SPECIES # ==> "canis lupus"  
puts Dog::SPECIES # ==> "canis lupus familiaris"

Of course, Ruby being the extremely permissive language that it is, actually allows you to change the values of constants, and merely throws a warning when you do:

Dog::SPECIES = "felis silvestris catus"
# ==> WARNING: already initialized constant SPECIES 

So, another option up your sleeve (again, for non-mutable class attributes) is using inheritable class methods:

# sh$ irb
  
class Wolf
  def Wolf.species
    "canis lupus"
  end
end
  
puts Wolf.species # ==> "canis lupus"
  
class Dog < Wolf
end
  
puts Wolf.species # ==> "canis lupus"  
puts Dog.species # ==> "canis lupus"
  
class Dog
  def Dog.species
    "canis lupus familiaris"
  end
end
  
puts Wolf.species # ==> "canis lupus"  
puts Dog.species # ==> "canis lupus familiaris"

This is option is also straightfoward. However, through the magic of monkey patching, a user of your library could still change the value returned by Dog.species - and this time Ruby won’t even throw a warning! :-)

def Dog.species
  "felis silvestris catus"
end
  
puts Dog.species # ==> "felis silvestris catus"
puts Wolf.species # ==> "canis lupus"      

Doh! In the end, there’s probably not much you can do to make something truly immutable in Ruby. Ruby treats you like an grown up - it gives you rules, but offers ways for you to break them, and trusts that you know what you’re doing.

Mutable class attributes

So what if we want mutable class level attributes that are unique in memory through inheritance? Before we result to using any libraries out there for accomplishing this, lets see what we can do with the base language itself:

# sh$ irb
  
class Wolf
  def Wolf.species
    @species ||= "canis lupus"
  end
  
  def Wolf.species=(value)
    @species = value
  end
end
  
puts Wolf.species #==> "canis lupus"
Wolf.species = "wolfy wolf"
puts Wolf.species #==> "wolfy wolf"

Notice that I’ve used “@species” in Wolf.species instead of “@@species”. “@species”, in that context, is a /class/ instance variable - it’s unique to the Wolf eigenclass, and points to a unique location in memory.

Another way to write Wolf would have been:

# sh$ irb
  
class Wolf
  class << self
    attr_accessor :species
  
    def species
      @species ||= "canis lupus"
    end
  end
end
  
puts Wolf.species #==> "canis lupus"
Wolf.species = "wolfy wolf"
puts Wolf.species #==> "wolfy wolf"

Based on a recent poll about class method declaration preferences (which I will post a link to as soon as I can find it), it seems that the vast majority of Rubyists would prefer the way we first defined the “species” and “species=” class methods. However, since a ton of popular Ruby code uses the latter approach, you should definitely familiarize yourself with it.

Now, let’s see what happens when we inherit from Wolf

class Dog < Wolf
end
  
puts Wolf.species #==> "wolfy wolf"
puts Dog.species #==> "canis lupus"

Success! Now all that’s left to do is give the Dog its proper species value:

# sh$ irb
  
class Wolf
  def Wolf.species
    @species ||= "canis lupus"
  end
  
  def Wolf.species=(value)
    @species = value
  end
end
  
class Dog < Wolf
  def Dog.species
    @species ||= "canis lupus familiaris"
  end
end
  
puts Wolf.species #==> "canis lupus"
puts Dog.species #==> "canis lupus familiaris"
Wolf.species = "wolfy!"
Dog.species = "puppy!"
puts Wolf.species #==> "wolfy!"
puts Dog.species #==> "puppy!"

If you want an even more concise method for accomplishing this same task, check out class_inheritable provided by rails

The latest release of my Dupe gem (v0.5.1) includes POST, PUT, and DELETE intercept mocks out of the box. Up to this point, it only had GET intercept mock support.

What does this mean in terms of ActiveResource? Now you can run “create”, “save”, and “destroy” on your ActiveResource::Base derived instances and Dupe will mock the services for these out of the box.

For example:

  irb# require 'dupe'
    ==> true

  irb# Dupe.define :author
  
  irb# class Author < ActiveResource::Base; self.site = ''; end
  
  irb# Dupe.find :authors 
    ==> []
  
  irb# a = Author.create :name => 'Frnk Herbert' 
            # --> handled by a Dupe POST intercept mock
  
  irb# Dupe.find :authors 
    ==> [<#Duped::Author name="Frnk Herbert" id=1>]
  
  irb# a.name = 'Frank Herbert' 
  
  irb# a.save 
         # --> handled by a Dupe PUT intercept mock
 
  irb# Dupe.find :authors 
    ==> [<#Duped::Author name="Frank Herbert" id=1>]
 
  irb# a.destroy 
         # --> handled by a Dupe DELETE intercept mock
  
  irb# Dupe.find :authors 
     ==> []

As you might expect, you can override the default POST, PUT, and DELETE intercept mocks you get for free when you define a resource, and you can also create your own custom intercept mocks for those methods. Checkout the “ActiveResource” section of the README for more information.

Special thx to Rachel Ober for her help in creating these new features.

Based on some valid feedback on my binder gem, I’ve refactored my code, simplified it where possible, and scaled it back to its most basic essentials. The “bind” class method is now packaged in a “Binder” module. When you require ‘binder’, the gem will no longer automatically monkey patch Object, polluting your namespace. Instead, you’ll have to extend your class with the “Binder” module before you can use the “bind” method.

If, however, you’re cool with the old functionality, which, in essence, adds a new reserved word to the ruby language (“bind”), you can require “binder/pervasive”.

Check out the README.rdoc for more info.