Ruby has quite an ornate grammar, so the first thing I tried broke in opal. I opened an issue.
Looking through the issue tracker there are a number of other ruby features which are unimplemented/implemented poorly. Like blocks: https://github.com/opal/opal/issues/130
It’s a nice idea, but they have a long slog ahead of them to implement ruby.
If you try to reimplement the Ruby grammar yourself, you’re gonna have a bad time.
This is still a neat project, even though it will probably only be a toy.
There are two known good ways to re-implement the ruby grammar
cargo cult what’s in parse.y, EXPR_MID and all. (There seems to be a bunch of unused lexer states that appear in every attempt).
use a generalized parser and disambiguate the parse tree later.
The ruby grammar is somewhat ambiguous, so either you have to disambiguate in the lexer, or the parser. The lexer route is the parse.y technique – using the symbol table, and having the parser change the lexer state to force it to return specific tokens (DO_COND/DO_LAMBDA, etc). The parser route is cleaner, but comes with the cost of GLR parsing.
The ruby grammar is somewhat ambiguous, so either you have to disambiguate in the lexer, or the parser.
Well, if it ever gets beyond the toy stage, it would be fun to build a Ruby VM by cross compiling it to JS and evaluating it with V8. It would provide a third Ruby VM that actually compiles to machine code (Rubinius and JRuby being the only others I know of).
I know there’s at least one MRI bytecode vm written in JS, but I can’t think of the link now