Gears Within Gears

In Ioke, a macro is a method that receives its arguments unevaluated. Instead of receiving a series of arguments, it receives a message. All code in Ioke is represented by message chains. A message looks something like this:

Take a look at that call to each. It receives two arguments, separated by a comma: the name of the variable to bind the incoming variable to, and the code for the loop. It’s equivalent to the following code in Ruby:

It’s pretty similar, except that in Ruby a block represents a special syntax form. In Ioke, calls to each follow the same syntax rules as any other kind of call, except that each is written as a macro, not a method. In the case above we don’t want to evaluate that first argument (name), because it doesn’t actually represent anything in the local scope. If you tried to evaluate it, you’d receive an error:

Macros allow a programmer to pick apart the arguments they receive and choose to evaluate them or not evaluate them, or evaluate them in particular contexts, as they so choose. They’re enormously powerful, but can be tricky to use, because without a structured argument list you’re never quite sure what you’re getting without taking a close look at the incoming message chain.

That’s where destructuring macros come in. dmacros are special kinds of meta-macros that allow you to write your code based on what you’re expecting from an incoming message. Here’s an example of a simple dmacro used by Message to allow you to turn transform any arbitrary code you give it into a message:

Think of them as a bit like multimethods: they perform the hard work of macro argument matching and allow you to write code that’s more clear and structured than it would otherwise be. Note that you still get access to the low-level call information that a regular macro would receive, so you can perform special tricks with the incoming arguments or the rest of the message chain if you’d like.

I’ve added an HTML formatter for Ioke’s testing framework, ISpec, and added TextMate bundle commands for test runners that use that formatter. I’ve shamelessly ripped off RSpec’s HTML formatter for a similar, though much less polished, style, and the results look something like this:

Because if you’re testing comprehensively, in my experience, you almost never need them. Unit and functional tests aren’t a panacea, but failures around incorrect types represent a miniscule proportion of the errors in the Ruby codebases I’ve worked on. You get them every once in a blue moon, but they are fixed easily and quickly, and everyone moves on with their lives. People still ask me sometimes if I miss static types, and my answer is always an unequivocal no. They eliminate a particular type of error that I almost never need to worry about.

Ola is also right that types aren’t the same as classes, and attempting to conflate the two will in all likelihood drive you towards class explosion and, ultimately, madness and penury.

That isn’t to say that interfaces shouldn’t have at least implicit contracts. In my own design, I try to follow the robustness principle whenever possible, and it improves code maintainability dramatically (nor does it does get discussed as a design principle nearly often enough). If it’s generally clear from reading the code what you can expect back from a method call and your types are suitably polymorphic then explicit type checks should be pretty rare.