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.