The Maybe Monad in Ruby | Hacker News Reader

The Maybe Monad in Ruby

blog.pretheory.com

16 pointswastedbrains9 comments

This is just like the Gang of Four pattern fetish that sprung up in the 90s, then people saw "patterns" everywhere, and everything had to be named. Its like that with Monads, suddenly people are seeing then in ordinary things all over the place.

It's a very traditional OO situation: you want a value that know how to handle its error case. Haskell makes it easy to implement that with types. Either you can check the integer return value (which your compiler can't verify), you can hack something up similar to it (return all the values in a list, say, and check how long that it), or you can see that a list is also a Monad, and Nothing looks like [] and Just x looks like [x].

In Rails, there's a file whiny_nil.rb, whose sole job is to report errors about people accessing a nil object when they shouldn't be. Using Maybe with pattern matching, coming from Haskell, makes as much sense as implementing Iterator with first-class functions. It looks weird, coming from Visual Basic, but it makes your code readable and short.

No question its a good thing, I am just amused at the "look ma, its a monad" craze going on. But if people are getting excited over FP concepts, thats nothing but a Good Thing (as long as it doesn't turn into a fashion, which will then go away).

Pretty Sweet. Here's my hacked together Python version (not sure what Monads have to do with it):

  class Maybe:    
    def __init__(self, obj):
        self.o = obj

    def __repr__(self):
        return repr(self.o)

    def __getattr__(self, name):
        try:
            return Maybe(getattr(self.o,name))
        except:
            return Maybe(None)

I'm trying to decide whether using it's Pythonic or not.

Are you sure you want to use __repr__ in this way? You'll end up with 'None' instead of None at the end.

Eh, I don't think the repr matters much. What does matter is actually getting all of the other methods implemented (stuff like cmp, eq, etc.). They're all basically pass-throughs, though. Even with that, I think it's still broken in some ways. I should learn more about what Python does for type conversions.

Rather than an explicit Maybe I've always wanted something built into the language. Why can't the language check for null customers in customer.id? I'd prefer customer.id to == null if customer is null.

I think the problem is that often you really do want to know if customer is nil. The nice thing about having to explicitly specify this is that you localize the effects - and make it clear in your code that you want this 'pass-through' behavior in a specific part of your code.

If you wanted this behavior everywhere, you could just include this code

  class NilClass
    def method_missing(method, *args)
      nil
    end
  end

But I think this would cause more problems than it would solve.

Very nice, I always wondered the same thing about chaining together conditionals.

Reply on news.ycombinator.com