Feature #5482
closedRubinius as basis for Ruby 2.0
Description
I'll give you three great reasons why:
- It's Ruby in Ruby (mostly).
- Ruby is better.
- Read #1 and #2, again.
As Rubyists, if we truly believe that Ruby makes software development more enjoyable and more productive, then it only stands to reason that Rubinius be the future of Ruby.
Updated by headius (Charles Nutter) almost 13 years ago
I think we should roll back to Evan's original pure-Ruby implementation and get rid of all that nasty C++. After all, if we truly believe that Ruby makes software development more enjoyable and more productive, then it only stands to reason that we should eliminate all non-Ruby languages from Ruby implementations.
Also...JRuby instead!
Updated by ko1 (Koichi Sasada) almost 13 years ago
(2011/10/25 12:46), Yusuke Endoh wrote:
Come back when all 1.9 features and callcc are implemented :-)
Off topic:
I plan to propose that removing callcc from 2.0.
--
// SASADA Koichi at atdot dot net
Updated by headius (Charles Nutter) almost 13 years ago
Remove fork, the C extension API, and ObjectSpace, and JRuby can be the new Ruby 2.0!
Updated by spatulasnout (B Kelly) almost 13 years ago
Charles Nutter wrote:
Remove fork, the C extension API, and ObjectSpace, and JRuby can be the new Ruby 2.0!
Add the JVM to the list and I'm sold!
;)
(Sorry Could Not Resist)
Bill
Updated by headius (Charles Nutter) almost 13 years ago
How about we run on the Dalvik "I swear I'm not a JVM" VM and call it even? I think it can even fork!
Updated by normalperson (Eric Wong) almost 13 years ago
Charles Nutter headius@headius.com wrote:
I think we should roll back to Evan's original pure-Ruby
implementation and get rid of all that nasty C++. After all, if we
truly believe that Ruby makes software development more enjoyable and
more productive, then it only stands to reason that we should
eliminate all non-Ruby languages from Ruby implementations.
More seriously, I agree that Ruby should be used whenever it makes sense
and I feel MRI uses too much C.
However, I still spend more time with MRI (than Rubinius) for the
following reasons:
-
From my experience, Rubinius aims to provide a Ruby environment.
I don't want a "Ruby environment", I want Ruby to be a /part/ of my
existing Unix environment (which includes sh/awk/sed/perl among
others). I like MRI startup is still reasonably fast. I can
easily swap out existing pieces of awk/sed for one-off Ruby scripts
instead of one-off C programs when I need something I can't do as
easily in awk/sed.I could use Perl instead of Ruby, but I prefer Ruby to Perl as a
language. -
I have no interest/skill in debugging/fixing C++ bugs in Rubinius.
I usually fix C bugs in MRI without much effort. I suspect
more potential contributors are capable of debugging/fixing C code
written_by_other_people than C++.
Of course, more Ruby code would open the door to more maintainers, still.
With better Ruby APIs (like String#byteslice in 1.9.3) and proposed
non-blocking IO methods[1], I think more parts of MRI could be
implemented in Ruby without significant performance loss.
Updated by headius (Charles Nutter) almost 13 years ago
On Tue, Oct 25, 2011 at 5:15 PM, Eric Wong normalperson@yhbt.net wrote:
More seriously, I agree that Ruby should be used whenever it makes sense
and I feel MRI uses too much C.
I agree wholeheartedly. This is perhaps the biggest reason I want MRI
to phase out the current C extension API in favor of one that's less
invasive, and why I'm excited for any promising JIT work for MRI. If
MRI can run Ruby fast enough, there will be less motivation to keep
moving libraries into C. That will make my life (and Evan's life) a
whole lot easier.
However, I still spend more time with MRI (than Rubinius) for the
following reasons:
And those are also reasons I don't think MRI will go away any time
soon. Suggestions to the contrary are just plain silly.
MRI is the most compatible Ruby implementation.
MRI is for many things still the fastest Ruby implementation (startup
time, some POSIX situations, C extensions).
MRI has the largest pool of regular contributors.
MRI is a solid, known quantity.
I will often recommend MRI when people need things that MRI does
better than JRuby, like fast startup, low-level POSIX stuff, or
features we can't support like callcc and fork. MRI is a vitally
important part of the Ruby implementation world.
Now, it would be nice if MRI didn't make changes to "Ruby the
language" without some direct participation and buy-in from the other
implementers, but that's a completely separate issue.
With better Ruby APIs (like String#byteslice in 1.9.3) and proposed
non-blocking IO methods[1], I think more parts of MRI could be
implemented in Ruby without significant performance loss.
Agreed. And those APIs could easily translate to other
implementations, giving us a much smaller implementation target to
keep up with. Let's make it happen!
- Charlie
Updated by Anonymous almost 13 years ago
On Mon, Oct 24, 2011 at 9:58 PM, SASADA Koichi ko1@atdot.net wrote:
(2011/10/25 12:46), Yusuke Endoh wrote:
Come back when all 1.9 features and callcc are implemented :-)
Off topic:
I plan to propose that removing callcc from 2.0.Can we have partial continuations instead? They allow for much better
optimization and have been shown to be more powerful. shift/reset style
continuations, maybe?
Updated by headius (Charles Nutter) almost 13 years ago
On Tue, Oct 25, 2011 at 11:45 PM, Tim Felgentreff tim@nada1.de wrote:
Can we have partial continuations instead? They allow for much better
optimization and have been shown to be more powerful. shift/reset style
continuations, maybe?
Fun hack of the night: https://gist.github.com/1315794
I'm sure it's not perfect, but it runs simple things correctly.
- Charlie
Updated by mame (Yusuke Endoh) almost 13 years ago
Hello, Charles
2011/10/26 Charles Oliver Nutter headius@headius.com:
On Tue, Oct 25, 2011 at 11:45 PM, Tim Felgentreff tim@nada1.de wrote:
Can we have partial continuations instead? They allow for much better
optimization and have been shown to be more powerful. shift/reset style
continuations, maybe?Fun hack of the night: https://gist.github.com/1315794
I'm sure it's not perfect, but it runs simple things correctly.
That is not a partial continuation.
A shift should first evaluate the given block, and then
jump to the corresponding reset with the result.
The execution must not return to reset's block.
reset { 2 * shift {|k| 2 } } #=> must be 2, not 4
The feature can be implemented by using callcc.
require "continuation"
def shift
callcc {|c1| $ctn[yield(proc {|v| callcc {|c2| $ctn = c2; c1[v] } })] }
end
def reset
callcc {|c| $ctn = c; v = yield; $ctn[v] }
end
You may think you can implement the feature in pure Ruby
by an exception or catch/throw. But I guess it is
difficult because it requires reentrant to a shift's
block. For example,
p reset { [1] + shift {|j| [2] + j[[3]] } + shift {|k| [4] + k[[5]] } }
prints [2, 4, 1, 3, 5].
It is difficult for me to explain how it does in English :-)
I just show a pseudo reduction diagram:
p reset { [1] + shift {|j| [2] + j[[3]] } + shift {|k| [4] + k[[5]] } }
#=> reset { [1] + [3] + shift {|k| [4] + k[[5]] } }
#=> reset { [1] + [3] + [5] }
#=> reset { [1] + shift {|j| [2] + j[[3]] } + shift {|k| [4] + [1,3,5] } }
#=> reset { [4,1,3,5] }
#=> reset { [1] + shift {|j| [2] + [4,1,3,5] } + shift {|k| [4] + k[5] } }
#=> reset { [2,4,1,3,5] }
#=> [2, 4, 1, 3, 5]
Check out Olivier's original paper if you are interested.
- Olivier Danvy and Andre Filinski (1990). "Abstracting Control".
If callcc would be removed in 2.0, we should lose a right
to play with such an interesting puzzle. Bummer.
--
Yusuke Endoh mame@tsg.ne.jp
Updated by headius (Charles Nutter) almost 13 years ago
I think it is more important for Ruby to be fast, expressive and easy to use
rather than filled with "interesting puzzles" but perhaps I am in a minority
there. In any case, I doubt that 99% of developers would care if callcc went
away, and it is not supported in several implementations already.
- Charlie (mobile)
Updated by naruse (Yui NARUSE) about 12 years ago
- Priority changed from 5 to Normal
mruby should be the basis of Ruby 3.0.
Updated by ko1 (Koichi Sasada) over 11 years ago
- Assignee set to matz (Yukihiro Matsumoto)
Some spies may be here.
Updated by hsbt (Hiroshi SHIBATA) over 6 years ago
- Status changed from Open to Rejected
We are working Ruby 3.0 now.