All the Perl that's Practical to Extract and Report

The language is still changing, there is no spec ...

nicholas on 2008-03-17T10:09:14

"The language is still changing, there is no spec for the language, there are going to be differences between implementations that are essentially undefined behavior."

The Register has an article about Ruby.NET with a lot of quotes from the project manager, John Lam, such as the one above. However, the spec is not something they can do anything about, so they have no choice. But one that caught my eye was one they do have some choice over:

Some familiar features will not be implemented, however. "Call with current continuation, we're not implementing that. [Although] JRuby isn't either. ...

It makes me ask myself a couple of questions, but not being familiar with Ruby or .NET, I don't know the answer to either. Does my usually silent readership know:

  • How often is call with current continuation used in typical Ruby programs? Would its absence be noted frequently?
  • Why do both the .NET and Java VM implementations of Ruby choose to omit it? Are continuations something stonkingly hard to make work well on their VMs? Would such a problem constrain any attempts to make Perl 6 run nicely on the VMs?

call/cc

Tony Finch on 2008-03-17T11:21:17

Call/cc requires lots of support from the VM, and if the VM isn't designed for it it'll cripple your performance if it isn't completely impossible. To implement call/cc you either need to allocate all stack frames on the heap (which requires an allocator and garbage collector optimised for very high rates of garbage production) or you need to be able to copy the stack when a continuation is captured. While you can implement heap-allocated activation records on the JVM and .net, it's much slower than using the native stack.

Call/cc is only really needed for implementing things like exceptions, co-routines, and other control abstractions that do complicated things to the call stack. They aren't necessary if you have a decent set of control structures built in to your language.

Re:call/cc

chromatic on 2008-03-17T17:50:39

They aren't necessary if you have a decent set of control structures built in to your language.

They aren't necessary if you have the precise set of control structures that you really need built into your language. That's slightly different from what you said.

As for the Nickclarkulator's second question, Larry's put in a fair bit of work to make sure that it's possible to host a Perl 6 implementation without exposing continuations. Part of that may have been the desire to get Perl 6 running on the Perl 5 VM in a reasonably efficient way (though Simon and I figured out how to support continuations there at YAPC::2006).

Re:call/cc

Aristotle on 2008-03-17T19:58:10

Wait, does that mean PerlŠ6 itself does not have continuations?

Re:call/cc

chromatic on 2008-03-17T20:48:17

I think (and Larry's really the one to ask here) that the goal is to support as much of the specification tests as possible without requiring continuations. They're still in the language though.

No "callcc" in Ruby 2.0?

draegtun on 2008-03-17T15:05:23

I believe continuations are being dropped from Ruby 2.0 all together. If so then probably not worth other VM implementations doing it.

http://lambda-the-ultimate.org/node/1801

Web Frameworks

djberg96 on 2008-03-17T15:34:08

How often is call with current continuation used in typical Ruby programs? Would its absence be noted frequently?
In typical Ruby programs? Never. The only serious use I ever saw for them was a continuation based web framework call Borges, which was itself based on Seaside.