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.
Existing 3rd-party packages rely on continuations:
For instance, the very popular and useful ruby-breakpoint package is
designed around continuations.
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.
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.
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.
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).
In message “Re: Concerns about removal of continuations in Ruby 2.0”
on Tue, 31 Oct 2006 18:08:45 +0900, “Alder G.” [email protected] 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.
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 forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
