> slightly out of date: http://programmingisterrible.com/post/42432568185/how-to-par...

Ouch.... Perhaps a lesson in making your language's grammar too complex: if you do, you'll eventually have to pre-compile.

So has Ruby joined the ranks of languages that formally cannot be parsed due to the halting problem?

I know Perl is in that category.

I don't think so. There are a few things that looks distinctly iffy in that respect on the surface, but they are resolved.

e.g. is "foo" a method call or an instance variable? You can't know in isolation, but it doesn't matter at parse time, as if it's part of a larger construct that is only valid as a method call, such as if there's an argument list after "foo", it is parsed as a method call. E.g:

    foo = 1
    foo(42)

will result in:

    test.rb:4:in `<main>': undefined method `foo' for main:Object (NoMethodError)

I think all of the potential cases that might have otherwise made Ruby impossible to formally parse are resolved in similar ways.

Now, there are certainly layering violations. The aforementioned example of "foo" by itself can only be resolved by determining whether or not "foo" is in scope as a local variable at the point it is referenced, for example, but you can opt to defer the decision until after parsing.

> So has Ruby joined the ranks of languages that formally cannot be parsed due to the halting problem?

No I don't think anyone has suggested that, have they?

ruby has a parse.y yacc grammar source file (linked to from the post I linked), and yes it can be parsed separately from being executed.

However, IIRC, no one has been able to re-implement parse.y; jruby and the other ruby re-implementations copied it and made what adaptations were necessary.

I've seen similar results with perl bytecode.

Our syntax probably isn't simpler :)