In this episode, Kevin and I talk more about Parrot and objects, other Ruby implementations, and some of the sources Kevin's been working with.
The big news in alternative implementations was a shootout by Antonio Cangiano. While I think this is still a bit premature (only YARV and Ruby 1.8.5 complete 100% of the tests, see chart below), there's a lot to learn from it. I think it can help each of the alternative implementation projects to see where they can focus some of their effort to really improve their version of Ruby.
I know Cardinal been blocked by the lack of solid Object support in Parrot so far, but what do you think can be done to help get Cardinal 'over the hump' so that you (and other contributors) can really get some momentum going?
Kevin: Attempts could be made to work with the current object system in Parrot. Having seen the trouble others have had with the current object system, I have decided that it is not worth my time to work with the object system as is.
Allison Randal has checked in a PIR based MOP called Simple Meta Object Protocol (SMOP). SMOP in its current form only supports attributes and parent classes. Support for methods needs to be added. I have the initial translation of SMOP to C based PMC coded up. The translation however, depends on the ability to call C PMC methods from C with PIR calling conventions. I have a plan to implement this functionality and call it PMINVOKE. This is the corresponding piece to PMETHOD functionality which I recently added to Parrot. PMETHOD allows C PMC Methods to be implmented with PIR calling conventions.
You've talked about wanting to build a MOP based object system, what advantages does that have for Cardinal and Parrot?
Kevin: MOP is a huge win for Parrot. MOP will allow common Parrot infrastructure pieces to be reused to implement the distinct object systems features that each language has. Parrot developers hope that a common Meta-MOP will permit the different object system philospohies of each language to interoperate at some common denominator level. At a minimum a common Meta-MOP will permit language implementor write object system translators. JRuby is having to do this with the Java and Ruby object systems, but without the help of any low level tools or common meta object subsystem.
As you see the JRuby and rubinius teams moving ahead, what pieces of their work do you think will apply to Cardinal?
Kevin: I think the knowledge base that they possess will be beneficial to Cardinal. The JRuby and rubinius projects currently trade and share a lot of insights about the problems areas of MRI. I'm a little disappointed that the alternative implementations have not built more common infrastructure in Ruby itself. Parsing is a real problem. I believe alternative implementors should build a common ruby parsing library to support rich parsing constructs that would make parsing ruby easier. Building a parsing framework is difficult, but adding code generation backends to a completed parsing framework would be relatively easy. Antlr and Perl 6 Rules are excellent examples of parsing frameworks with multiple code generation back ends. I am as guilty as the next implmentor in this respect, because Parrot provides a very rich parsing framework (Perl 6 Rules) which I'm proponent of.
Dan talked about using the plethora of papers on optimizing register based compilers to help improve Parrot. What papers and/or projects are you watching to help with your work?
Kevin: I've read the traits papers that discusses role composition. I've also checked out and read the CLOS MOP book. The traits papers have been very educational. The unanswered question is how to compose or accomidate state. I think a mix of the C++ multiple inheritance paradigm and explicit annotations as advocated by the traits papers may be the solution for composable state.
Given Kevin's work with on and MOP, the only sponsor that made sense this week was The Art of the Metaobject Protocol
. Grab a copy and learn more about MOP while supporting these interviews.
If you enjoyed this, you might also enjoy Nick Sieger's Serial JRuby Interview:
- Episode 1, in which Charles, Thomas, and Ola talk about their plans for JRuby.
- Episode 2, in which Charles, Thomas, and Ola talk about cooperation with the rubinius team and YARV.
- Episode 3, in which Charles, Thomas, and Ola talk about cooperation with the rubinius team Rails and (more about) YARV.
- Episode 4, in which Charles, Thomas, Ola, and Tor Norbye talk about JRuby and NetBeans.
- Episode 5, in which Charles, Thomas, and Ola talk about groovy.
James Gray has also started a serial interview. He's talking with Matz and Koichi. His first episode introduces them and discusses the recent merger of the VM formerly known as YARV and Ruby 1.9.
You might also enjoy my new Serial XRuby Interview or the original serial interview with the rubinius team.
