From: Brian Candler Date: 2012-03-25T00:59:07+09:00 Subject: Re: Specification for the Ruby Language(current) Tony Arcieri wrote in post #1053038: > My understanding is the existing formal written language specification > covers both Ruby 1.8 and Ruby 1.9, and in doing so is often too generic > as > to be useful in order to cover both cases. That is to say, where 1.8 and > 1.9 differ, the written spec says something that is inclusive of both, I'd say this is clearly documenting 1.8. For example: "15.2.10.5.2 String#+ +( other ) Visibility: public Behavior: a) If other is not an instance of the class String, the behavior is unspeciļ¬ed. b) Let S and O be the contents of the receiver and the other respectively. c) Return a new direct instance of the class String the content of which is the concatenation of S and O." If only Strings could be described so succinctly in ruby 1.9. That spec clearly says that String#+(other) is defined for all strings S and O, and that's not the case in ruby 1.9. Since there is no official documentation I had a go at understanding ruby 1.9 String a couple of years ago - I got as far as reverse-engineering about 200 different behaviours, many of them arbitrary, and then gave up. In any sane programming language, I think you should be able to describe in one or two sentences things like "when are two strings equal?" or "given that a and b are Strings, when does a + b raise an exception?" Probably the only accurate way to document 1.9 is to say "the behaviour of String is whatever it does in MRI ruby 1.9.XpY - go read the source code". But I also agree with you that the spec document is "too generic to be useful". For example, there are programs which rely on the "undefined" behaviour for String + non-String in ruby 1.8: >> class Foo; def to_str; "GOTCHA"; end; end => nil >> f = Foo.new => # >> "hello" + f => "helloGOTCHA" So any other ruby implementation written in conformance with the spec but which behaved differently would not be compatible. Hence the spec is actually pretty useless; it merely defines a family of "ruby-like languages" Furthermore, any attempt to form a language spec based on ruby 1.8, when the core ruby team have clearly said that they are abandoning 1.8 in favour of 1.9, can only have two outcomes: (1) the spec becomes irrelevant, as there are no implementations which conform to it; or (2) ruby will fork into two sets of implementations, those based on 1.8 and those based on 1.9 (*) Personally I would prefer (2) because then I continue to have a ruby-like language I can work with. But then to avoid confusion it needs to be called something other than "ruby". It's been a while since I heard anything about the cut-down "rite"... maybe that's the language to standardise and specify, and leave 1.9 in its murk. Regards, Brian. (*) Yes, jruby does both. -- Posted via http://www.ruby-forum.com/.