dmajda

I believe that the classical generated parser has generally better performance potential - there is less function calling, less string passing (but this may be avoided easily in combinators too) and more opportunity for optimalization if you have the whole grammar AST in hand.

ECMAScript 5 PEG parser: http://boshi.inimino.org/3box/PEG/build/ES5.html

(Hmm, I must definitely try to port it to PEG.js :-)

As for Ruby, I am not sure if it is even possible to create a PEG grammar. Its lexer and parser are heavily interconnected and there is a lot of state involved. If the grammar will be created, I don't think it would be pretty.

Interesting, thanks for the warning. I only skimmed through the paper today and noted that the algoritm seems complex, but I didn't attempt to understand it in detail.

What was your final result? Did you implement the left recursion in the way the paper describes, invented/found some other way or abandoned the whole idea?

I knew somebody would raise this point :-) You are right that the evaluation order would be wrong for "-" and "/".

I will probably implement support for left recursion in PEG.js - it is possible (see e.g. http://www.vpri.org/pdf/tr2007002_packrat.pdf). After that, the grammar could be rewritten to evaluate in the correct order.

(Another alternative - which works right now - is to change the parsing expressions to something like "additive ([+-] additive)*" and deal with the whole chain of operations with the same priority at once. I didn't use this in the example as I wanted it to be as simple as possible.)

What exactly you didn't like?

Thanks :-)

The source code is available on my website: http://www.majda.cz/download/translating-ruby-to-php-cd.tar..... I didn't push it on GitHub because I didn't indend to develop the compiler further after finishing the thesis.

The code is BSD-licensed however, so if anyone wants to hack on it, he is free to go :-)

I begun to work on the master thesis when there was no mod_rails, Rails hostings were less common and they were more expensive than PHP hostings. So the other commenters in this thread are right about the "deployability" reason.

When the work was being finished, I aleready saw that the real-world usefulness of the compiler is minimal. This is why I didn't develop the compiler further after finishing the thesis.

The PCNTL extension is about process control, not threading. I don't see how it could help to solve the limitations mentioned in the section 7.1 of the thesis.