Forum: Ruby Concerns about removal of continuations in Ruby 2.0

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
B780ee0ee1480454a85df58536702f63?d=identicon&s=25 Alder Green (alder)
on 2006-11-07 10:48
(Received via mailing list)
1. Certain control flow structures rely on continuations:

For instance, Ruby's generator implementation requires them[1].
Generators provide the canonical - most natural and convenient -
solutions for problems as typical as iterating over two or more Arrays
in parallel, simple suspended execution, resumable functions, and
others.


2. Existing 3rd-party packages rely on continuations:

For instance, the very popular and useful ruby-breakpoint package is
designed around continuations.


3. Certain possible features and packages need continuations:

The most obvious example is continuations-based web frameworks like
Seaside. The Ruby community has always been living on the cutting edge
of web technologies. Lack of continuations might prevent Rubyists from
pursuing one of the most interesting recent developments in
web-programming technology.

-Alder
A9b6a93b860020caf9d2d1d58c32478f?d=identicon&s=25 Ross Bamford (Guest)
on 2006-11-07 10:48
(Received via mailing list)
On Tue, 2006-10-31 at 18:08 +0900, Alder Green wrote:
> 1. Certain control flow structures rely on continuations:
>
> For instance, Ruby's generator implementation requires them[1].

Not any more - check out generator.rb in 1.9 (though what'll happen if
we lose green threads too, I don't know).
0ec4920185b657a03edf01fff96b4e9b?d=identicon&s=25 Yukihiro Matsumoto (Guest)
on 2006-11-07 10:49
(Received via mailing list)
Hi,

In message "Re: Concerns about removal of continuations in Ruby 2.0"
    on Tue, 31 Oct 2006 18:08:45 +0900, "Alder Green"
<alder.green@gmail.com> writes:

|1. Certain control flow structures rely on continuations:
|2. Existing 3rd-party packages rely on continuations:
|3. Certain possible features and packages need continuations:

Yes, yet they are few.  What I said were:

  * Ruby 1.9.1 will not have continuation, since they have lowest
    priority and are difficult to implement efficiently.

  * no promise (neither positive nor negative) on continuation for
    1.9.2 or 2.0, for exact same reason above.

							matz.
Ede2aa10c6462f1d825143879be59e38?d=identicon&s=25 Charles Oliver Nutter (Guest)
on 2006-11-07 10:49
(Received via mailing list)
Yukihiro Matsumoto wrote:
>
>   * Ruby 1.9.1 will not have continuation, since they have lowest
>     priority and are difficult to implement efficiently.
>
>   * no promise (neither positive nor negative) on continuation for
>     1.9.2 or 2.0, for exact same reason above.

 From a JRuby perspective, we could support continuations, but with the
same or greater limitations on their utility. With no continuation
support at the VM level, we would need to avoid deepening the Java call
stack to allow continuations to function. This isn't too terribly
difficult to do for pure Ruby code, but quite difficult and a
performance hit for Java code. It's also impossible to do with
third-party libraries involved that aren't designed with microthreading
or stackless execution in mond. There are tools that can microthread
existing code after-the-fact, but that's purely experimental.

Of course I don't believe a language should be developed with platform
limitations in mind, or I'd be using Groovy...but in this case the
difficulty of implementing continuations efficiently, portably, and
correctly with native threads and external libraries involved almost
seems to outweigh their utility. But I'm not a language design maven, so
I will not offer my opinion on whether continuations are a worthwhile
feature. Suffice it to say I haven't seen any *practical* applications
of continuations that couldn't be implemented in a less abstract (but
possibly more verbose) way.
2c51fec8183a5d21c4e11b430beabb47?d=identicon&s=25 Patrick Hurley (Guest)
on 2006-11-07 10:50
(Received via mailing list)
On 10/31/06, Charles Oliver Nutter <charles.nutter@sun.com> wrote:
> limitations in mind, or I'd be using Groovy...but in this case the
> difficulty of implementing continuations efficiently, portably, and
> correctly with native threads and external libraries involved almost
> seems to outweigh their utility. But I'm not a language design maven, so
> I will not offer my opinion on whether continuations are a worthwhile
> feature. Suffice it to say I haven't seen any *practical* applications
> of continuations that couldn't be implemented in a less abstract (but
> possibly more verbose) way.

I will agree that they are rarely used (at least in Ruby), but for a
nice use case see wee (http://www.ntecs.de/blog-old/Wee) or Seeside
(in smalltalk, but more active: http://www.seaside.st/).

That being said, Matz's goal of delivering 1.9.1 without continuations
makes sense as they are rarely used in Ruby (possibly due to their
inefficiency and/or the richness of Ruby's existing flow control/block
semantics).

pth
3bb23e7770680ea44a2d79e6d10daaed?d=identicon&s=25 M. Edward (Ed) Borasky (Guest)
on 2006-11-07 10:55
(Received via mailing list)
Yukihiro Matsumoto wrote:
>
>   * Ruby 1.9.1 will not have continuation, since they have lowest
>     priority and are difficult to implement efficiently.
>
>   * no promise (neither positive nor negative) on continuation for
>     1.9.2 or 2.0, for exact same reason above.
>
> 							matz.
>
>

An old saying in programming language design states that the toughest
part of language design is knowing what to leave out. Given that, if it
is decided to leave continuations out of 1.9.1, perhaps it is wiser to
leave them out "forever", or at least until Ruby 3.0.

Of course, *I* want to see them stay in "forever", so this is all
rhetorical. :)

Incidentally, the Carbone project (Ruby VM using the "vmgen" base) is
indeed inactive -- I asked the developer. I haven't looked at the source
yet, but I just might, given that.
This topic is locked and can not be replied to.