From: Alexandru Popescu Date: 2005-08-19T04:50:32+09:00 Subject: Re: Ruby Specifications #: Dion Almaer changed the world a bit at a time by saying on 8/18/2005 9:33 PM :# > On the other hand, I have seen far too much pain wrt specs and standards > bodies. > > D > I think I am aware of who/what are you talking :-). But I would say that even a spec would break the `most expected behavior� nature of Ruby, it can bring a lot of good things (including the ones you already mentioned - and I think more trust in it - not that Matz is not enough :) ). I think that this way the community will be able to focus and speed up on obtaining more stable and different environments. Also from the point of view of post-newbies this can represent a very nice reference. I am aware of the fact that this may represent a huge effort and would most probably require Matz' full commitment, but I still think that it will pay back ;-). :alex |.::the_mindstorm::.| >> -----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. >> > > > > >