User login

Navigation

Monads in Ruby

Monads in Ruby, a several-part work in progress, is an attempt to explain and demonstrate monads in Ruby. It looks pretty good so far, although I feel like we could coax a friendlier syntax out of Ruby with a little effort. Maybe in Part 4!

Of course monads doesn't. Say it is a kind of journalism for Ruby geeks who want to know why Haskellians are so excited about monads without learning Haskell, understanding it's deeper motivations and/or reading Wadlers articles which are quite beautiful but also kind of philosophical. Maybe this is also an affective demystification or expressed more positively: an enlightenment preventing fear ( black magic! ). "Look how simple monads really are", "see what all the buzz is about". We can do so too. One does not really get the point, but what is done out there by weird functionalists in the wilderness doesn't harm us.

Spending some time in programmer communities actually helps in understanding their primitive mentality.

The main intent here is to demystify them, rather than trying to make them useful in Ruby per se.

Not sure I would make cracks about "primitive" mentality, though. Those sorts of issues with the novel are a consistent trait of humanity.

Monads are only less mystical for FPers because they already have the conceptual/cognitive tools to address them. In my case I've also got to subtly include a gentle education in functional programming.

That's far from the only reason functional programmers use monads. For example, they allow control over side-effect propagation via the type system. They also make it possible to build new varieties of side-effect, some of which might be mutually exclusive with others. In fact, working with a customised monad can often feel rather like aspect-oriented programming...

Ruby probably doesn't need monads, at least not in the sense that Haskell needs them. But monads can be used to elegantly express a whole variety of useful programming patterns: nondeterminism, backtracking, exceptions, delimited continuations... Monads provide an excellent framework for transparently threading hidden state through a program. Implementing any of the above examples requires some kind of programming discipline in any case (passing extra arguments, trampolining, special return value conventions, ...), and monads give you a well-understood, structured way to approach that discipline, give you "one place to do it", and can ease the burden on the end programmer. They also come with a whole legacy of useful formal results. Like group theory, once a problem is modeled monadically, you might get a lot of new insight for free.

Besides, Scheme is as imperative as Ruby (where it counts), and monads still come in handy...

We describe a variety of logic programming constructs in terms of monads and monad morphisms and a reconstruction of all-solution predicates in terms of list comprehensions in \lambdaProlog. Novel monad structures are described for lazy function lists, clause unfoldings and a monad morphism based embedding of Prolog in \lambdaProlog is given. Not limited to \lambdaProlog, most of our techniques are usable in logic programming languages which implement a call/N built-in.

I'd welcome any feedback the LtU readership might have. I can manage in functional-land, obviously, but I'm still weak on the formal side of things.

While I'm deliberately playing a bit fast-and-loose in the first few chapters, I plan on getting increasingly formal in successive ones (e.g. the proof that Maybe obeys the monad laws should be less hand-wavey than that offered for Identity), so I want to make sure I get it right.

(Any suggestions re: the friendlier syntax, by the way? I haven't been able to think of anything particularly good...)

(Any suggestions re: the friendlier syntax, by the way? I haven't been able to think of anything particularly good...)

No, but it really seems like it should be there... This is one of my gripes with Ruby... You can play with the syntax, but it doesn't feel too nice. It feels like you're simply overloading existing syntax to mean something new, rather than really extending it (Lua works this way, too). So you have to be very clever to figure out how to sneak your feature into the syntax. With macros, you can design from scratch.

One other question: did you catch my pun in the original post? "Maybe in Part 4"? I thought it was so clever!

My draft tutorial on monads has been mentioned around here enough times that I really think I need to make it clear that it's nothing more than a draft, by no means authoritative, not in any way peer reviewed, a work in progress, etc etc. That doesn't mean it's useless, but there are a number of arguable points. You'll notice the original conversation where it came up was never concluded...