On Monday evening, the various Ruby implementers (sans John Lam since he had a schedule conflict) got together on FreeNode IRC in #ruby-core to discuss various design and future-related agenda items.

Here's the agenda and IRC log, and here's a rundown of what was discussed.

Class and Module Constant Scoping

Evan Phoenix had the first item, a question about the behavior of constant scoping in classes versus modules. For example, the following snipit:

class A; end
class B; end
A::B # will find B above, but print a warning

module C; end
module D; end
C::D # will complain it can't find C::D

The reason for this is that the :: operator only searches the class hierarchy for constants. So in A::B, only A and its superclasses get searched. Since this includes Object, and B is defined at the top level, A::B finds B. But since this is probably not the behavior the user wanted, given that they were explicitly scoping the lookup to B, a warning is printed. By the same logic, C::D does not find the top-level D, because modules do not have superclasses.

Evan made the point that if the "class fallthrough" behavior is warned against, perhaps it is intended to be removed or deprecated. Though there was some discussion about the issue, it was mostly tabled and we decided it should be discussed at length on the ruby-core mailing list if there's anything more to discuss. I suspect it won't come up again.

Multiple VM Support Discussion

As you may know, Sun Microsystems and the Univesity of Tokyo are collaborating on a Multiple-VM specification and implementation for Ruby. The primary folks involved are me, Tom Enebo, and Koichi Sasada, creator of the Ruby 1.9 VM (YARV). So this agenda item was mine.

Largely, the MVM situation looks like this:

• JRuby already has fairly complete and production-ready MVM support, since each JRuby runtime is "just an object" and you can have as many active as you like. But we lack a formal API and have no explicit APIs for cross-VM communication and control. The JRuby MVM support is how we're able to run multiple Rails instances in a single JVM, something no other implementation has achieved.
• Rubinius has a simple implementation of MVM, with a standard API and support for cross-VM communication and control. But largely, nobody's using it, and like the rest of Rubinius it's not "production ready".
• Ruby 1.9 (YARV) has neither support for MVM nor any API prepared to host it. The bulk of the work then would ultimately fall on Koichi and the ruby-core folks to both implement MVM and implement the APIs we decide upon to support it.

So the discussion largely focused on APIs and what we want them to do. In general, most folks agreed that sub-VMs should be largely independent from one another, but have a simple communication mechanism. While pipes were suggested, most agreed they were too low-level and would lead to each program implementing their own "wire protocol" unnecessarily. The model Rubinius takes is to allow passing messages of only integral types: String, Symbol, Numeric, Array, and Hash. I strongly prefer this model over the low-level pipe version and over anything more complex, since more complicated protocols can easily be built upon it. Rubinius also does this as fully asynchronous message passing, though it's unclear whether that would be a requirement of the MVM API or not. We also mostly agreed that if "forking" a VM in-process were ever to be supported, it would come after the first round of work on MVM. As far as I'm concerned, fork needs to die a flaming death RSN.

We closed out this item by getting the MVM list and wiki information out to people and encouraging more discussion. Hopefully this one will pick up a bit; I'd really love to put a standard API face on JRuby's excellent MVM support.

RubySpec and ruby-core

The final two agenda items we covered mostly focused on the RubySpec specs and how we can get the ruby-core folks to use them, contribute to them, and otherwise bless them as some sort of "official" specification effort. Brian Ford started out with an overview of the spec status, how they're run, where they're being used. Currently JRuby, IronRuby, and Rubinius all use the specs, though only JRuby and Rubinius developers are actively contributing back to it. The ruby-core team expressed some concerns. Will this mean replacing Ruby's existing test/ dir? How easy is it to run the specs? Do they require features we have changed/are changing in 1.9/2.0? Can we host them in the Ruby repository?

In general the discussion we very productive. One by one we tried to address their concerns, and I think we made a great case for them to start using and contributing to the specs. They were also interested in getting a list of spec failures we'd seen against Ruby 1.8.7pre2 (Vladimir handled my action item for that...thanks Vladimir!), and I suggested that Brian write up a simple "how to" to send to ruby-core, so they'd all understand the process and how it's supposed to work. I think we're getting very close to having ruby-core use and bless the specs as being a required part of Ruby development. And that's just fine with me.

Next Meeting

We scheduled the next meeting for the same time (9PM CDT, 11:00JST) on Apr 30/May 1. Here's the current agenda for the next ruby design meeting