in reply to Re: I wrote an expression parser for PPI
in thread I wrote an expression parser for PPI

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.

Replies are listed 'Best First'.
Re^3: I wrote an expression parser for PPI
by LanX (Saint) on Jan 08, 2026 at 15:46 UTC
    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]

      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.

[reply]
[d/l]
        I'm not sure how or if PPI handles prototyped subs.

        But I bet you need to take care in your project to handle them manually when they are exported. PPI as static parser might not attempt to recognize try {} beeing exported by use Try::Tiny ...

        Good luck with that.

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

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom