Ruby Specifications

[Brian Mitchell]

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?

Brian.

 

[Phil Tomson]

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

 

[Charles Steinman]

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?

I don't think now is a very good time to write out a specification,
because the specifics are in flux as we move on to Ruby 2. Maybe once
the language is a little more stable again it would be a good idea.

In any case, I don't think we could ever have a purely spec-driven
system. If the specs were out of sync with Matz's Ruby, I imagine it
would be the specs that change, not Ruby. So it would mainly be a
descriptive thing. That's what I think.

 

[Josh Charles]

I don't think now is a very good time to write out a specification,

because the specifics are in flux as we move on to Ruby 2. Maybe once
the language is a little more stable again it would be a good idea.

Is there a roadmap somewhere that contains a list of planned features
or what we might expect from further updates?

 

[Brian Mitchell]

=20

=20
I don't think now is a very good time to write out a specification,
because the specifics are in flux as we move on to Ruby 2. Maybe once
the language is a little more stable again it would be a good idea.
=20
In any case, I don't think we could ever have a purely spec-driven
system. If the specs were out of sync with Matz's Ruby, I imagine it
would be the specs that change, not Ruby. So it would mainly be a
descriptive thing. That's what I think.
=20

This might be the exact reason to use specs. Forward looking
development would be part of a spec with an included set of RCRs. This
could then be matched by any implementation. It is a little more work
but it makes things easier to implement, follow, and understand IMO.

Wouldn't we want to make decisions on language merit rather than look
at current implementations for the easiest way to handle things?
Wouldn't Ruby 2 might be better as a spec first anyway? It can be
rather hard to follow all of the experimental features going in and
out of ruby. A spec would be an easy and evolving place to look.

Brian.

 

[Brian Mitchell]

=20
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.)
=20
However (the big HOWEVER) realistically, I doubt we'll ever have a spec i= n
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.
=20
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.
=20

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.

=20
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 o= f
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 probabl= y
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 b= e
focused in other areas.
=20
Adding lots more testcases to Ruby's unit tests would probably be a good
way to go to acheive your goals.
=20

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.

 

[Dion Almaer]

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:[email protected]]
Sent: Thursday, August 18, 2005 2:21 PM
To: ruby-talk ML
Subject: Re: Ruby Specifications

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.

 

[Alexandru Popescu]

#: 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 standa= rds
bodies.=20
=20
D
=20

I think I am aware of who/what are you talking . But I would say that =
even a spec would break the=20
`most expected behavior=B4 nature of Ruby, it can bring a lot of good thi=
ngs (including the ones you=20
already mentioned - and I think more trust in it - not that Matz is not e=
nough ).

I think that this way the community will be able to focus and speed up on=
obtaining more stable and=20
different environments. Also from the point of view of post-newbies this =
can represent a very nice=20
reference.

I am aware of the fact that this may represent a huge effort and would mo=
st probably require Matz'=20
full commitment, but I still think that it will pay back ;-).

:alex |.::the_mindstorm::.|

-----Original Message-----
From: Brian Mitchell [mailto:[email protected]]=20
Sent: Thursday, August 18, 2005 2:21 PM
To: ruby-talk ML
Subject: Re: Ruby Specifications
=20

Over the past few days I've been working on implementing=20 my own (yet
another) Ruby interpreter. At first the simple things are easy to=20
match. With relative ease I was able to throw together modules,=20
classes, objects, and threads. However, moving further=20 down this path=20
I am finding that ruby has an very complex trail of=20 details in source=20
that have very slight but important effects.

If I am to match ruby as close as possible with this=20 project I will=20
have to have a very deep understanding of the ruby code base.
Unfortunately, I am not able to read Japanese at a=20 productive speed=20
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=20 community to=20
successfully write a compatible interpreter.

Doing all of this alone would seem like a waste as there are many=20
more projects that set out to do many of the same things and many=20
more that would benefit from this information. What I am=20 proposing is=20
a repository of sorts (a wiki perhaps) where we can maintain a=20
specification that is separate from implementation. It=20 seems the days=20
of a single implementation are soon ending. I think this is a good =
thing but without proper information we may run into portability=20
problems.

What do you guys think? Should we embrace a spec driven system or=20
just continue to use ruby as the reference implementation?=20 Should we=20
continue our current ways but have a spec as further documentation?=

=20
There are probably some good things that could come out of a=20
spec-driven system (as you imply, it would allow a thousands Ruby=20
implementations to bloom - errr, well, maybe that wouldn't=20 be the best=20
thing, come to think of it, maybe 3 or 4 blooming Rubys would be=20
sufficient.)
=20
However (the big HOWEVER) realistically, I doubt we'll ever have a=20
spec in the form that you dream of. Right now the Ruby=20 spec lives in=20
Matz' brain
- and it is implemented in the current Ruby/C implementation.
=20
I would suggest that perhaps we should view the current Ruby=20
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=20
verify your new implementation. Add unit tests where there=20 are deficiencies.
=20

=20
Right. I guess some work could be done to expand those to=20
complete coverage (or close to that in the real world). I'll=20
have to look deeper at them having neglected that angle.
=20

=20
A cautionary tale: There's a language for designing hardware called =
Verilog. Back in the mid-90's the IEEE decided that there=20 should be a=20
standardised Verilog specification. They made one, but there were=20
lots of holes in it. The first Verilog simulator was VerilogXL=20
produced by a company called Cadence. So what happens is that=20
VerilogXL (being the first implementation out there) is=20 considered the=20
gold standard. If your new implementation doesn't match=20 VerilogXL's=20
results then it will probably be considered wrong. But lots of=20
arguing will ensue, of course, when there are differences=20 with the new=20
implementor claiming that VerilogXL does it wrong. All this to say =
that a written spec isn't always all that useful and in=20 fact it may be=20
a waste of a lot of good energy that could be focused in=20 other areas.
=20
Adding lots more testcases to Ruby's unit tests would probably be a =
good way to go to acheive your goals.
=20

=20
A very good thing to note. I think a spec should be fluid.=20
That is, you have some standard specs (1.8, 2.0) and then you=20
append RCRs to them to signify places you've taken the=20
liberty to have some sort of change. I view this more as a=20
tool and a way to check behavior and portability than a restraint.
=20
I do think that this could be done successfully if enough=20
rubyists decided it is a good idea. It is a *big* undertaking=20
but so is managing a language that is growing at such an=20
astounding rate (not that I know much of anything from Matz's=20
point of view).
=20
Brian.
=20

=20
=20
=20
=20
=20

 

[David A. Black]

Hi --

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?

My memory is that Matz said, at one or more of the RubyConfs, that he
himself did not intend to devote the time to writing a formal language
spec for Ruby but had no objection in principle if people wanted to.
I'm not sure whether he indicated he might grant it official status.

As others have said, I think the test suite is a key measure of what
something that claims to interpret Ruby should do.


David

 

[Phil Tomson]

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".

I don't get it, what's the issue? Ruby as it exists in it's current form
is usable - How would a language spec make them feel any better? I could
see it if Ruby wasn't open source - then Matz could disappear and the
source code with him. But since the Ruby source is all over the place
even if Matz were to disappear (heaven forbid) Ruby would still be around
and usable.


Phil

 

[Lothar Scholz]

Hello Phil,



PT> I don't get it, what's the issue? Ruby as it exists in it's current form
PT> is usable - How would a language spec make them feel any better? I could

I think a language needs a formal specification.

If you have mission critical applications it's a little bit hard to
take this "C is the specification" argument.

I posted into the past that i really don't like it that matz break
compatibility in minor release changes. Suddenly returning a "[]" instead
of "nil" might be a small change but it can cost millions of dollars if it
happens in a critical environment.

If we had a specification for this it might restrict matz to make
changes like this, just because it feels better. This works for a
hacker language but i know that many companies got afraid when hearing
about this.

 

[zimbatm]

It could be intereting to make specifications, it could show where the
inconsistencies in the language are. This depends on how they are made.
In my experience, a text representation makes it difficult to link
foreign parts together, because my brain's buffer just isn't big enough
to contain the whole specs. Is it possible to have a visual expression
of the docs ?

In a similar context, I really like the Io grammar diagramm[1]. Does
anybody plan to do this for ruby ?

Cheers,
.... zimba

[1] http://www.iolanguage.com/docs/diagrams/grammar/

 

[Alexandru Popescu]

#: Phil Tomson changed the world a bit at a time by saying on 8/18/2005 11:26 PM :#

I don't get it, what's the issue? Ruby as it exists in it's current form
is usable - How would a language spec make them feel any better?

How can you convince/decide to invest/base your company when a change in the environment/language
can break your products?

How can you decide that an alternative env will serve you better when you cannot decide right from
the start that it offers at least the compatibility with the default Ruby?

Being around for some time I started to think that the most important asset of Ruby is Matz' head.
Sharing his ideas on some documents will make some of us feel better.

:alex |.::the_mindstorm::.|

 

[Tesla]

Hello Phil,

PT> In article <[email protected]>,


PT> I don't get it, what's the issue? Ruby as it exists in it's current form
PT> is usable - How would a language spec make them feel any better? I could

I think a language needs a formal specification.

If you have mission critical applications it's a little bit hard to
take this "C is the specification" argument.

I posted into the past that i really don't like it that matz break
compatibility in minor release changes. Suddenly returning a "[]" instead
of "nil" might be a small change but it can cost millions of dollars if it
happens in a critical environment.

If we had a specification for this it might restrict matz to make
changes like this, just because it feels better. This works for a
hacker language but i know that many companies got afraid when hearing
about this.

I think this is one of the reasons that PHP is controlled mostly by Zend
and the reason for Zend being. There was a great deal of compatiblity
issues surrounding the upgrading of php4 to OOP. The result was PHP5 and
the transistion to php5 from php4 is gradual and not mandatory (although
I think php4 is at the end of its cycle) for companies that have major
investments in PHP. So if Matz is thinking of making some heavy
changings that are outside of a spec then it would be cause for a branch
of Ruby rather than a teardown and the problems that come with it.

This is the one major problem I have with the Drupal CMS project. Point
version changes are major swings from the previous ones and cause a
tidelwave of work every 6 months. This means that companies will
continue to go with "enterprise" ready solutions like Typo3 and
ezPublish where the dev cycle is on point versions but major changes
without backwards compatiblity are very few.

My own selfish wish is that the Ruby dev mailing list be in english so I
can see what the core developers are working on.