I've been working on a parsing framework for Ruby since January called Treetop. I just released version 1.0.1 and recorded this screencast demonstrating its use.

(This is my proposal for this year's RubyConf. Fingers crossed!)

Treetop is a parsing framework that brings the elegance and simplicity of Ruby to syntactic analysis. Rather than being just another copy of classic LALR/LR based generators like Lex and Yacc, Treetop blends the unique expressive power of Ruby with cutting edge parsing research. Its "packrat" implementation enables recognition of parsing expression grammars, which dispense with the need for lexical scanning and can take advantage Ruby's mixin and inheritance model for composition.

Why can't I refer to constants nested inside a class within a module eval?

irb(main):001:0> class A
irb(main):002:1>    class B
irb(main):003:2>    end
irb(main):004:1> end
=> nil
irb(main):005:0> A.module_eval { puts B }
NameError: uninitialized constant B
           from (irb):5
           from (irb):5:in `module_eval'
           from (irb):5
           from :0

This is frustrating. Can anyone explain why it has to be this way? Perhaps there's a good reason I'm not considering.

On my next new project, I think I'm going back to Test::Unit. I've lost patience with Rspec, and it seems like I'm not alone. But I've spent more time praising and lobbying for it than some of its other current detractors, so I feel an explanation of my reversal is in order. First, I'll start off with what I like about Rspec, what got me to spend the time and energy switching to it to begin with.

I've always stressed that Rspec brings nothing fundamentally new to the table. For **'s sake, it's a testing framework. Setup. Teardown. Mocking. There's not a hell of a lot more to see. And that's okay. What's great about Rspec is that it lets you use real strings to label your test fixtures and cases. When I learned about it, I was struggling to name my test cases like sentences.

test_that_foo_does_bar_when_it_has_been_bazzed

Luckily, I'm a Dvorak typist so the underbar is close at hand, but not being able to freely compose descriptions of what I'm testing in a natural way can be very limiting. Writing helps me gather my thoughts, so the act of labelling the test can really help me. I take special pride in well written "it" strings. The describe block strings are also helpful, but not as big a deal to me. The clever assertion hacks are also cute and fun to write. The built in mocking is nice, but I'm not a big mockofascist, so I don't get too excited about it.

And... that's basically it. My appreciation for Rspec can be broken down as follows:

• 70%: String test fixture and case names
• 20%: .should be_valid etc
• 10%: Mocking

Now, what sucks about Rspec snuck up on me. It boils down to 2 things:

1. The framework is too f-ing complicated in its implementation.
2. The framework is too presumptive about how I wish to organize my tests.

The second is an aesthetic gripe, which I insist is fair game, since the framework's merits are mainly aesthetic anyways. The first is a much deeper issue. The semantics of a Test::Unit test fixture are straightforward. The test fixture is a class. It contains methods beginning with the word test. A seperate instance of the class is created, in which each test runs. A setup and teardown method run before and after each method invocation.

And that is more or less all I need to know. There's some stuff I'd like to have, like a global setup / teardown akin to before(:all), but I can what's there without really understanding anything about the framework's implementation. It rides on the semantics of Ruby, and I understand Ruby because I use it every day.

Rspec, on the other hand, sends me down a labyrinthine path full of Ruby meta-object-protocol tricks to accomplish even the simplest of tasks. And trust me, I have a pretty solid grasp of the MOP. I love it, use it, and cringe when people refer to it as "magic" (it's like assembly programmers calling a for loop magic or something). But there's use and then there's overuse. I myself can be accused of both. The eval family of methods is great. Therein lies the power to implement DSL's with their own semantics that can diverge quite dramatically from Ruby. Therein also lies the problem. I like classes. I like inheritance. I like the object oriented model. So if software written in an object oriented language can get away with employing the basic object oriented tools to accomplish its mission, well then it by all means should. I don't have time to dig around the BehaviorEvalModule, or whatever else I've looked at in myriad diversions to get Rspec to do something of medium hardness.

So I guess that's it. Rspec does the basics really well. Ridiculously beautiful stuff. But venture beyond the limited tracks they've laid and you're in the jungle. So anyway. I'm not ready to write the whole thing off yet, but I am going to revisit Test::Unit for a while, see if I might not give myself what I miss from Rspec atop its simpler implementation. We'll see if I come back.

This weekend I discovered the Q language. Check this out: Into a file called sq.q I type:

sq X = X * X;
X+(Y+Z) = (X+Y)+Z; X*(Y*Z) = (X*Y)*Z; 
X*(Y+Z) = X*Y+X*Z; (X+Y)*Z = X*Z+Y*Z;

This is the definition of square, followed by the laws for distributivity and associativity as they could be copied directly out of a textbook. Then I evaluate this file in the Q VM-based interpreter, whose speed apparently rivals that of the Glasgow Haskell Compiler or CLISP:

q sq.q

In the interepretter window I then type a term, and using my rules Q reduces it to normal form:

==> sq (A+B)
A*A+B*A+A*B+B*B

I am pretty sure this language is going to unleash an unreal amount of metaprogramming power. Term rewriting is a genius idea.

REST. What is it, and how can it be used to design better web applications?

A presentation at RailsConf did me a great service by first pointing out all the things REST is not. It isn't CRUD. It isn't pretty URLs. It is neither a protocol nor an architecture, but it can play a role in your implementation of all of the above. REST itself though, is less concrete than all of that. It is a theoretical framework, a way of thinking about designing distributed software systems. For me, the first step in absorbing its principles is to forget about the database and focus on the fundamentals. This article will start there, then drill down to show how these ideas can help organize the development of your Rails applications.

(Noon: Rest From Work (After Millet) by Vincent Van Gogh)