eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
REDMOND, Wash.—As more users are looking to use the Ruby language on .Net, developers are responding with solutions to enable it.
Using the Ruby language on the Microsoft CLR (Common Language Runtime) is doable if you maintain certain guidance, said John Gough, a professor at QUT (Queensland University of Technology) in Brisbane, Australia.
Ruby is an interpreted scripting language for quick and easy object-oriented programming.
Gough, along with partner, Wayne Kelly, another QUT professor, and a small team, have created a compiler for Ruby that enables it to run on the Microsoft CLR. The name of the compiler is the Gardens Point Ruby.NET compiler.
Gough spoke at the Lang.NET 2006 Symposium on the Microsoft campus on July 31. He said his team had been doing .Net compilers for some time and was interested in doing one for Ruby.
However, “Ruby involves some unique problems” that are specific to Ruby itself rather than to dynamic languages in general,” Hough said.
However, Gough noted that he was not trying to be critical of the object-oriented Ruby language. “Ruby has a community that can be fanatical at times,” he quipped.
However, among the implementation challenges Ruby represents for the CLR include mapping.
“The central issues have to do with mapping the type system and the implementation of such dynamic language staples as closure,” Gough said.
There also are issues of blocks in Ruby. Ruby enables methods to be attached to individual objects as opposed to just classes. They can be passed on a per object basis or as a block.
So the issue of blocks, continuations and dynamic inheritance present challenges to implementing Ruby on the CLR, Gough said.
However, Gough and his team have been constructing a Ruby compiler for six months now, he said. “Its a real compiler, not an interop wrapper,” he said.
The compiler recently went to a public beta release over the last few weeks, he added.
Sorting out the issues with Ruby on the CLR, Gough said, “The major problem with Ruby, as with a lot of languages, is there is no definition of the language semantics.”
However, “the thing that saves us here is the test suite, and the licensing conditions that allow you to experiment freely,” because the open-source licensing of the language encourages free reuse, he said.
Meanwhile, Gough noted that “everything in Ruby is an object with a well-defined class.” Yet, the problem is that a class definition cannot be extended at runtime and may be defined over several source files, he said.
So the classes in a Ruby program end up being represented in a small number of CLR classes, he said. In essence, Ruby classes are not represented one-to-one with the classes in the CLR, he said.
For its part, the current implementation of Goughs compiler concentrates on the “core language” of Ruby, he said. And the implementation passes more than 860 tests in the QUT test suite, Gough said.
Meanwhile, the groups interoperability system is in its early stages, “and we havent paid any particular attention to speed at this stage,” he said.
That is an issue because Ruby is “notoriously slow, but we have lots of ideas for speeding it up.”
In addition, Gough said the Ruby compiler project spawned the development of new tools in the QUT tools collection. One is the Program Executable File Reader/Writer (PE File Reader/Writer) API, also known as PERWAPI.
PERWAPI is a managed component which presents on the client side an API to read and construct program executable files, he said.
Also, early in the project Goughs team produced a C# parser generator known as the GPPG (Gardens Point Parser Generator), and the team is about to release a version of the Lex lexical analyzer generator, known as Gardens Point Lex, which emits C# and is designed to work with GPPG parsers.