From: Dion Almaer Date: 2005-08-19T04:33:39+09:00 Subject: Re: Ruby Specifications 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 wrote: > > In article , > > Brian Mitchell 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. >