BerntB has asked for the wisdom of the Perl Monks concerning the following question:

Hi all,
I could use some wisdom from the esteemed monks regarding a mildly insane hobby project of mine.

PPI does not parse expressions into an AST, nor does it assign list/scalar/null context. I’ve implemented that myself and put the code here: https://github.com/Percolisp/pcl.

I wrote this parser because it makes a full Perl ==> Common Lisp transpiler possible. There’s already a prototype compiler in the repository as well; please see REMAINING.md for details. Moo/Moose would likely need to be handled by mapping them onto Common Lisp’s object system. String evals will have to wait until the transpiler itself is transpiled to CL.

I think this could be useful. If nothing else, as a way to take the Lisp S-expression output and translate it into other languages. Does this sound worthwhile, or should I be doing something else instead? 🙂

Replies are listed 'Best First'.
Re: I wrote an expression parser for PPI
by LanX (Saint) on Jan 07, 2026 at 22:34 UTC
    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:

    • type casting of operators: something like 1+"" might produce very different results in Perl, JS and Lisp
    • error handling: Perl can die and warn where JS is just silently returning a NaN
    • other side effects like state changes
    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

[reply]
[d/l]

      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.

[reply]
[d/l]
[select]
        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.

[reply]
[d/l]

Back to Seekers of Perl Wisdom