The problem with "MRI as spec" is that nobody really knows how the language is defined.
E.g. large parts of the 1.8.x series behaved differently from what most people thought it did in terms of the bootstrapping of inheritance of core classes. I wrote a blog post about Ruby behaviour based on introspecting the 1.8.6 interpreter that some people insisted was wrong because it worked differently than intended. Yet the behaviour persisted for years until it silently changed at some point (I don't know which revision).
In that case it was no big deal since the reason the real behaviour was pretty much unknown was that nobody depended on the behaviour, but from what I've seen this is fairly common with MRI.
As a "spec" it is one of the most unstable environments I've worked with. Though I love Ruby the language, MRI is a problem as the default implementation and atrocious as a "spec".
I frankly hope one of the other implementations gains enough traction to force the core team to the "negotiating table" over a proper specification.
E.g. large parts of the 1.8.x series behaved differently from what most people thought it did in terms of the bootstrapping of inheritance of core classes. I wrote a blog post about Ruby behaviour based on introspecting the 1.8.6 interpreter that some people insisted was wrong because it worked differently than intended. Yet the behaviour persisted for years until it silently changed at some point (I don't know which revision).
In that case it was no big deal since the reason the real behaviour was pretty much unknown was that nobody depended on the behaviour, but from what I've seen this is fairly common with MRI.
As a "spec" it is one of the most unstable environments I've worked with. Though I love Ruby the language, MRI is a problem as the default implementation and atrocious as a "spec".
I frankly hope one of the other implementations gains enough traction to force the core team to the "negotiating table" over a proper specification.