Hi Ben. This first version attacks the most efficient way to use the bridge -- keep the Ruby and JavaScript parts as self-contained as possible, crossing the bridge only when absolutely necessary. A future version will likely provide the type of feature you are describing for use in scenarios where performance is less critical.
I've been looking into the JRuby / Rhino combination to implement server-side user plugins, where you can't trust the code[1]. I don't think it'll be that slow to let JS call Ruby code.
That said, I'm now wondering whether writing them in Java and using SecurityManagers plus byte-code verification and adding of checks for running too long in loops is the way to go.
[1] And of course, because it's Javascript, it can run in the browser too. With suitable shim code, you can then debug in Firebug. IDE for free!
Whether you would be able to call methods on it depends on whether the Snarl author did some (trivial) code magic or not, but it's certainly doable too.
Still I have no idea why would you want javascript in ruby in the first place.
With a stub DOM and Javascript interpreter, you can pass generated output from web application views directly into your testing environment and make assertions about the resulting behavior, dynamically-generated DOM nodes, etc.
There are a number of projects similar to this one (for which, sadly, I cannot currently pull up any bookmarks) mostly intended for a similar set of tasks. Being able to bring RSpec or Cucumber to bear on a hairy JS testing job can make the process much more enjoyable.
As for using Javascript from Ruby, it might be quite nice as a language to let your users write extensions and plugins. It's a language where the implementations all have an emphasis on sandboxing.