In article <firstname.lastname@example.org>,
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
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.
Brian Mitchell <email@example.com> wrote: