in reply to I wrote an expression parser for PPI

On a tangent:

One of my hobby projects/visions is to convert Perl to other languages, preferably JavaScript and my approach would be to patch B::Deparse - which is a pure perl module reverse engineering the complied op-tree to Perl.

Now the real problem isn't converting between different syntax, but covering the semantics of dynamic languages in an efficient way.

Just a few examples:

Bottom line: to produce efficient code you'll most likely have to sacrifice compatibility. Otherwise you have to code a lot of emulating code for seemingly simple operators.

Cheers Rolf
(addicted to the Perl Programming Language :)
see Wikisyntax for the Monastery

Replies are listed 'Best First'.
Re^2: I wrote an expression parser for PPI
by BerntB (Deacon) on Jan 08, 2026 at 12:50 UTC

    To shake out bugs and semantic differences, the plan is to run existing test suites from CPAN etc. It’ll probably take a few more weeks before the implementation is solid enough to run arbitrary Perl code.

    The pcl is intentionally naive. Speed, like XS support, is a problem for version 3. :-( The target is that we can start building Perl compilers now.
    In this version, all variables are boxed as small structs, even when no references are taken (or variables that are just numbers). Once the expression parser was done, putting together a proof-of-concept Perl compiler was pretty easy. (that was a weird sentence to write!) But to be sure, I haven't really thought about e.g. threads and string evals will be done when this compiler/transpiler is itself compiled to CL.

    I picked Common Lisp as a target because it has good compilers and the semantics should support Perl well. This $x + foo(5) is just translated to (pl-+ $x (pl-foo 5)). All Perl operators and built-ins are just mapped to functions/macros in a runtime. The output is readable to Perl programmers and also works as an intermediate representation for e.g. other compilers (Raku?).

    JavaScript would be really useful and has fast compiler, but it would be hard to compile XS to the browser (WebAssembly?). Most of a compiler's frontend should be solved with PPI and this project.

      Some thoughts

      To be really more useful than a exotic dialect of Perl you will need to implement eval too, since recompiling is the core of all require and use code.

      This means you'll also need to transpile your PPI-version.

      You might also be interested in Flavio Glock's work running Perl under JS and Java, IIRC he's still onto it and gave a talk at last LPW.

      > JavaScript would be really useful and has fast compiler, but it would be hard to compile XS to the browser (WebAssembly?).

      HaukeX's WebPerl already does that at roughly half speed. Using a hypothetical B::Deparse2JS could be used to speed up time consuming sub-routines (in a kind of JIT/afterburner way).

      My issue with WebPerl was that it's memory intensive and slow to start-up°, but I haven't looked into it since before the pandemic.

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      see Wikisyntax for the Monastery

      °) well maybe it's possible to hide this behind a web worker. And local caching in the browser would be a plus too.

        Ah yes, you are of course correct about eval. I will have to think about it. So it'll need a Perl process with a transpiler for evals, that will be slow. (I was planning to cache compiled Perl libraries that are use:d/require:d, it is high on the todo list.)

        I remember that Perl-in-the-browser Webassembly from before... Fun, but specialized.

        I remember Perlito, a subset so no CPAN modules? But I missed news about his PerlOnJava. That was cool! It is done by a real compiler guy. And he has done probably a work year more than me (I am just doing autovivification). But his JVM target is really ambitious, while I selected the easiest target possible (with PCRE etc). I hope he gets it to production ready.