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.


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.

Phil