I’d like to start this post by thanking everyone who’s involved in the various ruby implementations and the RubySpec project. Its fantastic seeing whats happening with MRI Ruby 1.9, JRuby, Rubinius, MagLev, MacRuby, etc. (sorry if I left you out)
This morning a tweet by Jim Weirich caught my eye leading to a document the “Ruby Draft Standard.” It is an interesting document which I have not spent enough time reviewing. I was curious to see how this document covered the language and the core libraries and how it might compare to the RubySpec During a quick read I noticed many statements of the form “the behavior is implementation dependent.” Simple search in Safari told me there were more than 100 of these references. My first reaction was “whoa, thats too many”
Jim tweeted, appropriately, that Ruby language implementers should have flexibility. I agree as there are many unique things that each implementation brings to the table and a flexible language like Ruby should embrace this. However, there are many cases in the Draft Spec where this flexibility might be sacrificing consistency in the face of flexibility.
One example is the method
String#*(num) about which the draft standard states
If the num is not an instance of the class Integer, the behavior is implementation dependent. On the surface this seems reasonable. However, the fine folks over at RubySpec have this to say: “tries to convert the given argument to an integer using to_int” This seems far more reasonable a behavior and supports the whole Principal of Least Surprise we love so much.
So, who’s right here? Will we have a two levels of specification, one for the core language with lots of “implementation dependent” behaviors that the implementers, through RubySpec, will then choose to specify or leave dependent?
I’ve been looking for a good way to contribute to the Ruby language so perhaps I’ll make a pass at trying to reconcile this Ruby Draft Standard against the RubySpec specs and see what shakes out. I suspect there are many “implementation dependent” entries that RubySpec has spec-ed into concrete behavior. Even better might be, if there is value here, to augment the RubySpec DSL to add traceability to this document. However, past lives have shown that documents with a numbering scheme like “18.104.22.168.1 String#*” tend to descend quickly into renumbering-hell.