Rite (Ruby)
This page contains changes that are awaiting review.
This is as of now mostly a copy of Matz's slides. Feel free to refactor and expand as needed.
Matz's keynote topic at Rubyconf 2003: "How Ruby Sucks"
The slides of this presentation can be found at: http://www.rubyist.net/~matz/slides/rc2003/
The new revision of the language will be Ruby 2.0; its implementation will be Rite. Sometimes one term is used to refer to both, but when meaningful Ruby2.0 and Rite will be considered as two separated entities. Both the language and the implementation will change.
Ruby2 will be slightly incompatible, the changes will not only consist of additions but also of syntax improvements (hopefully a better syntax will result).
Rite will be a bytecode based, thread-safe virtual machine. Care will be taken to make embedding easier than in 1.x.
Matz has planned a precise path that will lead to Ruby2.0 and its implementation, Rite.
After releasing 1.8.1, 1.9 will be started; it will be an experimental release, primarily for language experimentation, but 1.9 won't be "Rite". Ruby 1.9 development starts right after 1.8.1 Final.
Matz is "still waiting for a guru to finish Rite for him". Many fail to see the implications of this... for some background, read RubyTalk:76588 and RubyTalk:76603 The son-shi award is at stake!
Matz wants to
This means that 2, 3, 4 versions will contain major changes that could potentially break things. Sub-releases such as 2.x won't.
Ruby 1.9 is essentially going to be 2.0 in terms of syntax but not implementation. Some of the things that will be tested in 1.9 include
Ruby 2 will change:
Local variable scope will be changed. Matz considers them the "most regrettable behavior in Ruby". No "block local" variables by assignment. Block params will be block local, even if the same name variable exists previously, local variables in eval() die after eval, all block params will be local.
Matz stated before that shadowing would cause a warning -- it is unclear in his presentation whether this will be the case in the end or not.
def foo
a = nil
ary.each do |b|
#b is block local
c = b
a = b
# a and c are local to the method (i.e. NOT block local)
end
# a and c here
end
It will be possible to make them local to the class/module (so that derived classes won't be able to access them).
@variable # can be accessed by subclasses
@_variable # not accessible by subclasses
# "or the other way around"
@@variables are going to be local to the class/module. You will have to define accessors to get to them from outside.
class Foo
A = 1
B = 2
end
module Mod
B = 3
C = 4
class Bar<Foo
p Bar # => Mod::Bar (rule 2)
p A # => 1 (rule 1)
p B # => 2 (rule 1)
p C # => 4 (rule 2)
p D # => error! (rule 3)
end
end
a, b, c = x
where x = [1,2,3]
should they be:
a=1,b=2,c=3
or:
a=[1,2,3],b=nil, c=nil
Matz still hasn't decided, but it will be either:
print line if f.lineno == 1 .. f.lineno == 2
Matz wants to either remove or change it (he says he doesn't even know what that code snippet does ;)
def foo(a, b: 42, **keys)
p [a,b,keys]
end
#
foo(1) # => [1,42, {}]
foo(2, b:5) # => [2,5, {}]
foo(3, b:4, c:6) # => [3,4,{:c=>6}]
If you don't specify the double star argument, the unspecified keyword would be nil. Order is not important for keyword args; the variable "a" is positional in the previous examples.
foo(1,2,3) # => raises some kind of error
foo(1,b:2,c:3) # => this is correct
foo(1,c:3,b:2) # => this too
Matz is not sure yet about the kind of error that should be raised.
{a: 45, b: 55, c: 65}
same as:
{:a => 45, :b => 55, :c => 65}
class Foo
def foo:pre(*args)
p "pre"
end
#
def foo:post(*args)
p "post"
end
#
def foo:wrap(*args)
p "wrap pre"
super
p "wrap post"
end
#
def foo(*args)
p "foo"
end
end
#
Foo.new.foo
gives:
wrap pre
pre
foo
post
wrap post
"def" may return an object; doesn't know yet
class Foo
def foo:pre(*args)
end
end
Throws an error at time of definition, because no foo method exists to "pre" against.
But maybe not... Matz may change his mind on that (based on suggestion from audience)
Foo.new.foo:pre # NOT legal
It might be possible to encapsulate changes to classes (redefinition of methods, new methods, etc.) inside an arbitrary scope:
$a = "4"
namespace foo # syntax may change
class String
def to_i
0
end
end
p $a.to_i # => 0, in this namespace
end # of namespace
p $a.to_i # => 4
Some consequences to be expected would be:
There are a number of cons:
Matz finds the current typing systems (StrongTyping and types.rb) based on class/modules are too restrictive and hinder duck typing. He's looking for ideas to implement a system based on method signatures and integrate it in the VM core.
These are the things we knew already (from previous presentations or postings in the mailing list)
If GNU gcc is available, it will run faster (because of computed gotos)
Philosophy:
Free to make drastic RCR for limited time only until March 2004
An RCR should be more than mere "hope". The following information is required:
Matz showed HTTP://www.rubyist.net/~matz/slides/rc2003/mgp00034.html an example of what he expects a RCR to look like, advocating the removal of "proc", so that only "lambda" would remain (to prevent confusion with Proc.new and its different semantics). It is unclear whether he actually plans to carry this out.
The RCR blitz should happen before March/2004. Matz says "I think I will reject most of them" :-) RCRs will not happen on RubyGarden.org going forward. DavidBlack has created a HTTP://rcrchive.net site for RCRs.
Matz still needs time to consider RCRs... will wait for some
Rite will remain vaporware for a while
Here are some open questions it would be great if this page could answer:
Parrot is Perl6's upcoming virtual machine (HTTP://www.parrotcode.org). It has been designed specifically for Perl but some care has been taken to make it work with other languages (Ruby and Python come to mind). People from the Cardinal project planned to make a compiler targetting Parrot bytecode for Ruby, but the project seems frozen at the moment (no activity in the mailing list for months).
Parrot doesn't affect Matz's plans at all: he will make his own VM (Rite), which will be the reference implementation if Parrot is ever able to run Ruby code and becomes more popular than Rite.
Parrot promises top-notch speed and the ability to share libraries written in several languages; many people remain rather sceptical in that regard. It is widely believed that Matz's independent creation of a VM specific for Ruby could be completed faster and better than Parrot's all-encompassing goal.
You could experiment layering the Ruby 2 language parser on top of the Groovy (HTTP://groovy.codehaus.org/) AST model (which is a Ruby-like language) which compiles down to Java bytecode and sits snugly on top of the JVM, and has great integration with the Java platform. Then you'd have Ruby language with a VM and bytecode and threading model. Only downside is the C integration might not be as good as if you did your own VM & bytecode.
Just a thought: this could allow you to progress Ruby 2, the language, while a separate team writes a VM, etc.
-- JamesStrachan?
The JavaVM would be unacceptable for a great many of Ruby's users because it is non-free - or to avoid an argument over the meaning of "free", let's say "does not conform to the Open Source Definition." For some languages this might not matter, but for a language like Ruby I would suggest that it does.
The Kaffe VM would then be an option, but there is the same problem with C integration. And I think C integration is just about the most important thing for a scripting language.
Cacao devs have written a very fast Java interpreter that's automatically generated by vmgen, so it may be the right option for generating fast, portable Ruby interpreters that could be integrated alongside the existing core, without having to rewrite everything. Christian Thallinger will give a talk on vmgen integration in Cacao at FOSDEM 06 in the GNU Classpath developer room, so join us if you are around.
-- DaliborTopic?
But it might be worth evaluating presently-existing free virtual machines out there. The ones I have found so far are: Scheme48, GNU Smalltalk, gforth/vmgen, and LLVM.
-- anonymous
We dont need another VM. The JVM and CLR (.NET or Mono) are good virtual machines. They are already accepted into corporate environments. Most developers are working with one of them. Introducing another VM will only slow the adoption of Rite. At worst, it will prevent many developers from being able to use it on their job. If Ruby2 ran on the JVM and/or CLR it would see orders of magnitude more adoption and growth.
Ruby2 should focus on being a lauguage that is usable on any platform or VM. Please don't make it another island in the sea of virtual machines.
-- GregHouston
Read the section about RCRs.
See RubyTalk:96642