31st
Erlang’s Parametrized Modules Rock
Mochiweb introduced me to Erlang’s Parametrized Modules. Which are experimental, undocumented, and totally awesome. Why are they so great? Because they give you a marvelous mix of one of the best features of functional programming (no mutable state, which is a huge win in the massive concurrency world), with one of the best features of object-oriented programming (receiver polymorphism, where objects of different types know how to respond to a common set of methods).
(Note that I thought that Alex Martelli, author of the wonderful Python in a Nutshell, coined the term receiver polymorphism, but Google is not backing me up on this one. Maybe I’m making that term up right now).
Here’s why I’m all abuzz about that today: I need to create a tree of logical rules, much like an AST for a simple language. Once I’ve created it, I want to pass it some variables, and have it evalutate them. In python, I’d have a set of different classes for Rules, and have them all define an eval(self, params) method. Some of the rules will have children (e.g. logical AND), and will call child.eval(params) as part of their eval process. Note that there is absolutely no requirement for mutable state.
With parametrized modules, you can translate this scheme just about perfectly into Erlang. Any module which will implement a rule will take a set of params that define it’s creation time state (which never changes), and the internal methods of the module can refer to that state. Essentially, you’ve got instances with instance data that never changes (what is often called “value objects” in the OO world).
It’s lovely stuff. For the full story on parametrized modules, check out the PDF that defines them:
http://www.erlang.se/workshop/2003/paper/p29-carlsson.pdf
-Dan M
p.s. Where do I lobby to make these a permanent feature of Erlang?
