From: Yusuke Endoh <mame@...>
Date: 2012-12-11T22:33:37+09:00
Subject: [ruby-core:50758] Re: Ruby Implementers Meeting Summary

Aaron and drbrain, thank you for coordinating the meeting!
I've read the discussion log.


Please let me confirm my understanding first.  The current is:

  1. A feature proposal to "Ruby" requires only matz's approval.
  2. "MRI" specifies "Ruby" as a reference implementation.

You suggest changing these points to:

  1. A feature proposal to "Ruby" requires not only matz's approval,
     but also other implementors' approvals.
  2. "MRI" does NOT specify "Ruby", but "RubySpec" does.

Okay?


If I'm correct, I have concerns for each.  Let me state them.
(This is just my personal opinion; you can ignore it if you think
it is unfair to attempt to speak after the meeting)


For part (1), it is still difficult enough to get matz's approval.
Making feature request more difficult will make Ruby's evolution
slower, or even stopped.  I don't think it is a good idea.


For part (2), I'm not against.  I prefer "reference implementation"
style, though.  Anyway, you should first persuade brixen because
this requires RubySpec to change the policy about implementation-
defined behavior.

brixen said to me (in IRC) in the past:

  - The goal of RubySpec is to provide an executable spec for Ruby
    implementors to check their implementation to comply with "Ruby".

  - But, most people think "MRI" behavior as a official feature set
    of "Ruby" even if some of them are actually MRI implementation-
    defined behavior.

  - Thus, he regards "MRI" as "Ruby" ("the Standard" in RubySpec
    terminology) and tries to include all MRI behaviors (including
    implementation-defined one and undefined one) as a "spec".

I thought that his policy was consistent.  (brixen, please correct
me if I'm wrong)

However, if rubyspec now speficies "Ruby", it should accept
implementation-defined, undefined, or unspecified behaviors as is.

There are more MRI implementation-defined behavior than you expect.
For example, AFAIK, "Ruby" does not specify the Float internal
representation, while RubySpec assumes that it is IEEE754.

Such specs that "specifies" implementation-defined behavior, must
be removed from RubySpec.  I'm not sure if brixen is satisfied with
this fact.

-- 
Yusuke Endoh <mame@tsg.ne.jp>