Feature #5482: Rubinius as basis for Ruby 2.0

• Category set to Joke

Cute. +1.

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!

(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

Remove fork, the C extension API, and ObjectSpace, and JRuby can be the new Ruby 2.0!

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

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!

Charles Nutter <[e-mail]> 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: 1) 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. 2) 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. [1] http://redmine.ruby-lang.org/issues/5138

On Tue, Oct 25, 2011 at 5:15 PM, Eric Wong <[e-mail]> 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

On Mon, Oct 24, 2011 at 9:58 PM, SASADA Koichi <[e-mail]> 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?

On Tue, Oct 25, 2011 at 11:45 PM, Tim Felgentreff <[e-mail]> 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

Hello, Charles 2011/10/26 Charles Oliver Nutter <[e-mail]>: > On Tue, Oct 25, 2011 at 11:45 PM, Tim Felgentreff <[e-mail]> 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 <[e-mail]>

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) On Oct 26, 2011 10:18 PM, "Yusuke Endoh" <[e-mail]> wrote: > Hello, Charles > > 2011/10/26 Charles Oliver Nutter <[e-mail]>: > > On Tue, Oct 25, 2011 at 11:45 PM, Tim Felgentreff <[e-mail]> 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 <[e-mail]> > >