Who needs specs when you can just have exegenesis/apocalypse style fluffing
around? :)

A spec would be good from a "business" sense. I know of a few large
companies that are worried about "betting on one Japanese fellow". Also, a
spec + test cases would be nice if we really want multiple programs which
grok ruby syntax (I just want one that runs on a VM [I know several are in
the works] :)

On the other hand, I have seen far too much pain wrt specs and standards
bodies. 

D

> -----Original Message-----
> From: Brian Mitchell [mailto:binary42 / gmail.com] 
> Sent: Thursday, August 18, 2005 2:21 PM
> To: ruby-talk ML
> Subject: Re: Ruby Specifications
> 
> On 8/18/05, Phil Tomson <ptkwt / aracnet.com> wrote:
> > In article <fcfe41700508181054764fd3f9 / mail.gmail.com>,
> > Brian Mitchell  <binary42 / gmail.com> wrote:
> > >Over the past few days I've been working on implementing 
> my own (yet
> > >another) Ruby interpreter. At first the simple things are easy to 
> > >match. With relative ease I was able to throw together modules, 
> > >classes, objects, and threads. However, moving further 
> down this path 
> > >I am finding that ruby has an very complex trail of 
> details in source 
> > >that have very slight but important effects.
> > >
> > >If I am to match ruby as close as possible with this 
> project I will 
> > >have to have a very deep understanding of the ruby code base.
> > >Unfortunately, I am not able to read Japanese at a 
> productive speed 
> > >so the black book is out of the question for a large part of this. 
> > >The other option I have is to pool the knowledge of the 
> community to 
> > >successfully write a compatible interpreter.
> > >
> > >Doing all of this alone would seem like a waste as there are many 
> > >more projects that set out to do many of the same things and many 
> > >more that would benefit from this information. What I am 
> proposing is 
> > >a repository of sorts (a wiki perhaps) where we can maintain a 
> > >specification that is separate from implementation. It 
> seems the days 
> > >of a single implementation are soon ending. I think this is a good 
> > >thing but without proper information we may run into portability 
> > >problems.
> > >
> > >What do you guys think? Should we embrace a spec driven system or 
> > >just continue to use ruby as the reference implementation? 
> Should we 
> > >continue our current ways but have a spec as further documentation?
> > >
> > 
> > There are probably some good things that could come out of a 
> > spec-driven system (as you imply, it would allow a thousands Ruby 
> > implementations to bloom - errr, well, maybe that wouldn't 
> be the best 
> > thing, come to think of it, maybe 3 or 4 blooming Rubys would be 
> > sufficient.)
> > 
> > However (the big HOWEVER) realistically, I doubt we'll ever have a 
> > spec in the form that you dream of.  Right now the Ruby 
> spec lives in 
> > Matz' brain
> > - and it is implemented in the current Ruby/C implementation.
> > 
> > I would suggest that perhaps we should view the current Ruby 
> > implementation as an executable spec with a set of unit test cases
> > (Rubicon) that are used to verify it.  Use the same unit tests to 
> > verify your new implementation.  Add unit tests where there 
> are deficiencies.
> > 
> 
> Right. I guess some work could be done to expand those to 
> complete coverage (or close to that in the real world). I'll 
> have to look deeper at them having neglected that angle.
> 
> > 
> > A cautionary tale: There's a language for designing hardware called 
> > Verilog.  Back in the mid-90's the IEEE decided that there 
> should be a 
> > standardised Verilog specification.  They made one, but there were 
> > lots of holes in it.  The first Verilog simulator was VerilogXL 
> > produced by a company called Cadence.  So what happens is that 
> > VerilogXL (being the first implementation out there) is 
> considered the 
> > gold standard.  If your new implementation doesn't match 
> VerilogXL's 
> > results then it will probably be considered wrong.  But lots of 
> > arguing will ensue, of course, when there are differences 
> with the new 
> > implementor claiming that VerilogXL does it wrong.  All this to say 
> > that a written spec isn't always all that useful and in 
> fact it may be 
> > a waste of a lot of good energy that could be focused in 
> other areas.
> > 
> > Adding lots more testcases to Ruby's unit tests would probably be a 
> > good way to go to acheive your goals.
> > 
> 
> A very good thing to note. I think a spec should be fluid. 
> That is, you have some standard specs (1.8, 2.0) and then you 
> append RCRs to them to signify places you've taken the 
> liberty to have some sort of change. I view this more as a 
> tool and a way to check behavior and portability than a restraint.
> 
> I do think that this could be done successfully if enough 
> rubyists decided it is a good idea. It is a *big* undertaking 
> but so is managing a language that is growing at such an 
> astounding rate (not that I know much of anything from Matz's 
> point of view).
> 
> Brian.
>