Specification for the Ruby Language(current)

ruby-talk
1

Hello,

I have been wondering if there has been some updates since the publication
of the book by Flanagan and Matsumoto? I am curious how much I can expect
JRuby, CRuby etc. to still conform to this description? Is there some sort
of specification out there (similar to the Self specification or the Scheme
rnrs)?

Regards,

Carter.

2

It's impossible to know if a language conforms to an on-paper
specification, because an on-paper specification is on-paper and therefore
can't provide any way to check that a given implementation matches what has
been written down.

In order to do that sort of automatic checking, you need an executable
specification of the language, which is what RubySpec provides:

http://rubyspec.org/

In my opinion, this makes RubySpec a lot more useful than an on-paper
specification, which relies on end user feedback as they discover parts of
an implementation that don't match what's written down. An executable
specification can automatically tell you if you conform to it on a whim.

···

On Fri, Mar 23, 2012 at 6:20 PM, Carter Cheng <cartercheng@gmail.com> wrote:

Hello,

I have been wondering if there has been some updates since the publication
of the book by Flanagan and Matsumoto? I am curious how much I can expect
JRuby, CRuby etc. to still conform to this description? Is there some sort
of specification out there (similar to the Self specification or the Scheme
rnrs)?

Regards,

Carter.

--
Tony Arcieri

3

Hi Tony,

It would seem to me that both are needed since a programmer would have
difficulty referring to a non-text specification. Is the specification
autogenerated from the context free grammar? I am rather unfamiliar with
the notion of an executable spec.

Regards,

Carter.

···

On Sat, Mar 24, 2012 at 9:30 AM, Tony Arcieri <tony.arcieri@gmail.com>wrote:

It's impossible to know if a language conforms to an on-paper
specification, because an on-paper specification is on-paper and therefore
can't provide any way to check that a given implementation matches what has
been written down.

In order to do that sort of automatic checking, you need an executable
specification of the language, which is what RubySpec provides:

http://rubyspec.org/

In my opinion, this makes RubySpec a lot more useful than an on-paper
specification, which relies on end user feedback as they discover parts of
an implementation that don't match what's written down. An executable
specification can automatically tell you if you conform to it on a whim.

On Fri, Mar 23, 2012 at 6:20 PM, Carter Cheng <cartercheng@gmail.com>wrote:

Hello,

I have been wondering if there has been some updates since the
publication of the book by Flanagan and Matsumoto? I am curious how much I
can expect JRuby, CRuby etc. to still conform to this description? Is there
some sort of specification out there (similar to the Self specification or
the Scheme rnrs)?

Regards,

Carter.

--
Tony Arcieri

4

No, the Ruby language's specification is laboriously written by hand:

http://www.ipa.go.jp/osc/english/ruby/ruby_draft_specification_agreement.html

A language specification contains much more than just the grammar, it also
contains a formal description of the behavior of the language (i.e. its
semantics) as well.

Personally I find the RubySpec code examples much more useful than a formal
description of the language.

···

On Fri, Mar 23, 2012 at 6:51 PM, Carter Cheng <cartercheng@gmail.com> wrote:

Hi Tony,

It would seem to me that both are needed since a programmer would have
difficulty referring to a non-text specification. Is the specification
autogenerated from the context free grammar? I am rather unfamiliar with
the notion of an executable spec.

Regards,

Carter.

On Sat, Mar 24, 2012 at 9:30 AM, Tony Arcieri <tony.arcieri@gmail.com>wrote:

It's impossible to know if a language conforms to an on-paper
specification, because an on-paper specification is on-paper and therefore
can't provide any way to check that a given implementation matches what has
been written down.

In order to do that sort of automatic checking, you need an executable
specification of the language, which is what RubySpec provides:

http://rubyspec.org/

In my opinion, this makes RubySpec a lot more useful than an on-paper
specification, which relies on end user feedback as they discover parts of
an implementation that don't match what's written down. An executable
specification can automatically tell you if you conform to it on a whim.

On Fri, Mar 23, 2012 at 6:20 PM, Carter Cheng <cartercheng@gmail.com>wrote:

Hello,

I have been wondering if there has been some updates since the
publication of the book by Flanagan and Matsumoto? I am curious how much I
can expect JRuby, CRuby etc. to still conform to this description? Is there
some sort of specification out there (similar to the Self specification or
the Scheme rnrs)?

Regards,

Carter.

--
Tony Arcieri

--
Tony Arcieri

5

Thanks Tony. I was wondering if there was some official language
specification out there for the 1.9 series with either an operational or
denotational semantic description or something of that ilk.

···

On Sat, Mar 24, 2012 at 10:36 AM, Tony Arcieri <tony.arcieri@gmail.com>wrote:

No, the Ruby language's specification is laboriously written by hand:

http://www.ipa.go.jp/osc/english/ruby/ruby_draft_specification_agreement.html

A language specification contains much more than just the grammar, it also
contains a formal description of the behavior of the language (i.e. its
semantics) as well.

Personally I find the RubySpec code examples much more useful than a
formal description of the language.

On Fri, Mar 23, 2012 at 6:51 PM, Carter Cheng <cartercheng@gmail.com>wrote:

Hi Tony,

It would seem to me that both are needed since a programmer would have
difficulty referring to a non-text specification. Is the specification
autogenerated from the context free grammar? I am rather unfamiliar with
the notion of an executable spec.

Regards,

Carter.

On Sat, Mar 24, 2012 at 9:30 AM, Tony Arcieri <tony.arcieri@gmail.com>wrote:

It's impossible to know if a language conforms to an on-paper
specification, because an on-paper specification is on-paper and therefore
can't provide any way to check that a given implementation matches what has
been written down.

In order to do that sort of automatic checking, you need an executable
specification of the language, which is what RubySpec provides:

http://rubyspec.org/

In my opinion, this makes RubySpec a lot more useful than an on-paper
specification, which relies on end user feedback as they discover parts of
an implementation that don't match what's written down. An executable
specification can automatically tell you if you conform to it on a whim.

On Fri, Mar 23, 2012 at 6:20 PM, Carter Cheng <cartercheng@gmail.com>wrote:

Hello,

I have been wondering if there has been some updates since the
publication of the book by Flanagan and Matsumoto? I am curious how much I
can expect JRuby, CRuby etc. to still conform to this description? Is there
some sort of specification out there (similar to the Self specification or
the Scheme rnrs)?

Regards,

Carter.

--
Tony Arcieri

--
Tony Arcieri

6

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, but
perhaps too generic to be meaningful as a language implementer.

Again, your best bet here is going to be RubySpec, which actually includes
specific tests for both versions.

···

On Fri, Mar 23, 2012 at 8:03 PM, Carter Cheng <cartercheng@gmail.com> wrote:

Thanks Tony. I was wondering if there was some official language
specification out there for the 1.9 series with either an operational or
denotational semantic description or something of that ilk.

On Sat, Mar 24, 2012 at 10:36 AM, Tony Arcieri <tony.arcieri@gmail.com>wrote:

No, the Ruby language's specification is laboriously written by hand:

http://www.ipa.go.jp/osc/english/ruby/ruby_draft_specification_agreement.html

A language specification contains much more than just the grammar, it
also contains a formal description of the behavior of the language (i.e.
its semantics) as well.

Personally I find the RubySpec code examples much more useful than a
formal description of the language.

On Fri, Mar 23, 2012 at 6:51 PM, Carter Cheng <cartercheng@gmail.com>wrote:

Hi Tony,

It would seem to me that both are needed since a programmer would have
difficulty referring to a non-text specification. Is the specification
autogenerated from the context free grammar? I am rather unfamiliar with
the notion of an executable spec.

Regards,

Carter.

On Sat, Mar 24, 2012 at 9:30 AM, Tony Arcieri <tony.arcieri@gmail.com>wrote:

It's impossible to know if a language conforms to an on-paper
specification, because an on-paper specification is on-paper and therefore
can't provide any way to check that a given implementation matches what has
been written down.

In order to do that sort of automatic checking, you need an executable
specification of the language, which is what RubySpec provides:

http://rubyspec.org/

In my opinion, this makes RubySpec a lot more useful than an on-paper
specification, which relies on end user feedback as they discover parts of
an implementation that don't match what's written down. An executable
specification can automatically tell you if you conform to it on a whim.

On Fri, Mar 23, 2012 at 6:20 PM, Carter Cheng <cartercheng@gmail.com>wrote:

Hello,

I have been wondering if there has been some updates since the
publication of the book by Flanagan and Matsumoto? I am curious how much I
can expect JRuby, CRuby etc. to still conform to this description? Is there
some sort of specification out there (similar to the Self specification or
the Scheme rnrs)?

Regards,

Carter.

--
Tony Arcieri

--
Tony Arcieri

--
Tony Arcieri

7

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
unspecified.
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.
<http://github.com/candlerb/string19/blob/master/string19.rb&gt;

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

=> #<Foo:0x10cc6c458>

"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/\.