It's building a parse tree, and then attempting to use the unambiguous bits like an abstract syntax tree, presumably to side-step the statically unresolvable am

It's building a parse tree, and then attempting to use the unambiguous bits like an abstract syntax tree, presumably to side-step the statically unresolvable ambiguity mentioned in the previous article. And yes, that is as bizarre as it seems. I think this article is pretty disingenuous. It's trying to pretend that there is something really complicated going on here (e.g. "That's one way in which Perl 5 differs from other language implementations; it manages the artifacts of compilation itself"), when really, it's actually just poor design layered upon poor design. > Perl 5's execution model isn't quite the same as a traditional compiler (whatever that means) and it's definitely not the same as the traditional notion of an interpreter. There are two distinct phases of execution of a Perl 5 program: compile time and runtime. You must understand the difference to take full advantage of Perl 5. This is true, but only if you don't really understand what a traditional compiler or a traditional interpreter might entail, given that Perl is basically doing what Python, Ruby, Matlab and any number of other language implementations do, it's just doing it in such a way that it has to account for flaws in the design of the language.