At RubyKaigi 2008, Ruby's inventor Matz announced plans to standardize Ruby in order to "improve the compatibility between different Ruby implementations [..] and to ease Ruby's way into the Japanese government". The first proposal for standardization will be to the Japanese Industrial Standards Committee and in a further step to the ISO, to become an international standard. For now, a first draft (that weighs in at over 300 pages) and official announcement are available. Alternatively, there's a wiki under development to make the standard available in HTML format.
A very different approach to unite Ruby implementations is the RubySpec project (more RubySpec related news on InfoQ), a community driven effort to build an executable specification. RubySpec is an offspring of the Rubinius project:
The RubySpec project aims to write a complete executable specification for the Ruby programming language that is syntax-compatible with RSpec. [..] The specs generally serve two purposes: 1) to drive development, and 2) as a verification mechanism.
InfoQ talked to RubySpec's father Brian Ford to find out what he thinks about the standardization and what this means for RubySpec.
I think the ISO Standardization effort is very important for Ruby, both for the language and for the community, which in my mind includes the Ruby programmers, people who use software written in Ruby, and the increasing number of businesses based on or using software written in Ruby.
The Standardization document and RubySpec are complementary in my view. The document places primary importance on describing Ruby in prose with appropriate formatting formalities. The document envisions essentially one definition of Ruby.
RubySpec, in contrast, places primary importance on code that demonstrates the behavior of Ruby. However, RubySpec also emphasizes describing Ruby in prose as an essential element of the executable specification and is the reason we use RSpec-compatible syntax.
RubySpec also attempts to capture the behavior of the union of all Ruby implementations. It provides execution guards that document the specs for differences between implementations. For example, not all platforms used to implement Ruby support forking a process. So the specs have guards for which implementations provide that feature.
This illustrates an important difference between the ISO Standardization document and RubySpec. The ISO document can simply state that a particular aspect of the language is "implementation defined" and provide no further guidance. Unfortunately, implementing such a standard can be difficult, as we have seen with the confusion caused by various browser vendors attempting to implement CSS. RubySpec attempts to squeeze the total number of unspecified Ruby behaviors to the smallest size possible.
Once the ISO Standardization document matures, we will add some sort of tagging to RubySpec to enable an implementation to run all specs tagged as "ISO Standard". This would enable an implementation to claim that they faithfully conform to the behavior specified in the ISO document. I don't know yet if running the specs like this will be accepted by an agency (perhaps governmental) attempting to verify an implementation's standard compliance.
InfoQ: Will Rubinius be standards-compliant?
Absolutely. From the very beginning, I worked on RubySpec to ensure that Rubinius would be as faithful as possible to the "standard implementation" or MRI (Matz's Ruby Interpreter). We've worked very hard at this and there are very few places in RubySpec where we have added "not_compliant_on :rubinius" guards. Since the ISO Standard is more lenient than RubySpec, I expect we will have no problem being "ISO Standard" compliant.
The standard draft is based on Ruby 1.8.7, but Ruby 1.9.2 is already on the horizon. We asked Yuki Sonoda, Ruby 1.9 release manager, what the plans for Ruby 1.9 with regards to the standardization are:
The JIS/ISO standard draft was designed so that Ruby 1.9 conforms to it. So the draft is intentionally loose. It gives Ruby processors the minimum restriction to be a "Ruby". So even 1.8.7 needs stricter specification like RubySpec to keep compatibility between implementations.
From the other Ruby implementations, Monty Williams of Gemstone, the company behind MagLev, tells us what he thinks of the standardization efforts:
We certainly applaud the effort to come up with a Ruby standard. At a high level, an approved standard should help in increasing Ruby adoption in certain sectors. We expect we'll be able to assure MagLev is standards compliant once the standard is finalized.
InfoQ: Could the standard be useful in developing MagLev?
Much of the implementation work on MagLev preceded the draft standard. At this point what would help us most would be a compatibility test kit which certifies standards compliance, similar to the JCK. The RubySpec project is a great step in the right direction here.
However, the standard could be a big help to future implementors in figuring out Ruby details.
What do our readers think: will it be easier to introduce Ruby in their organizations if there's an ISO standard behind it?