Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

scrottie (4167)


My email address is Spam me harder! *moan*

Journal of scrottie (4167)

Friday January 25, 2008
05:04 AM

*My* Perl Wishlist (Hint: Not Your Wishlist)

[ #35482 ]

Perl 6 (as specified) exists as the sum of other people's wishes. Some of them are quite awesome. But here's what *I* want in Perl.

* I want to see the Perl grammar written in Perl. The optimizer has already been rewritten in Perl along with a means of plugging in additional optimizations (for fixing up the code to change it's semantics, inspect it for correctness, etc). Having the grammar in Perl will allow it too to be extensible.

* I want to see the various ops in the pp_*.c source files implemented in Perl. Educated readers will see where I'm going with this.

* I want to see a B::CC counterpart that works very, very well. Ops that store state in their own op structures will have to be modified to stop frickin' doing that in the spirit of ROMable code. That's .. and ..., at least.

At this point, Perl 5 is self hosting. Perl is written in Perl, and Perl compiles Perl down to machine code. This is important for a bunch of reasons. It's easier to modify and extend the language. Working in C is a PITA. Computers can do a better job optimizing large programs than humans have time or energy to. The interpreter would be retained, so programs can be run immediately or compiled and then run as a binary.

* Good static analysis done on the parse tree (which is the same as the bytecode tree) so that optimizations can be proved safe for the compiler. For example, a scalar could be proven to never hold anything but numbers, eliminating a lot of calls to pOK. Variables could be proven, in many cases, never to be tied, or having various other magic on them, eliminating large numbers of checks that are done on the variable before and during their uses in the present interpreter. Rather than inlining the contents of the pp_*.c definitions, a *subset* of the contents of the pp_*.c op definition could be inlined. There's no real win on compiling or JIT-ing until this kind of static analysis is done and it can be proven that large amounts of code can be omitted from the op definitions in specific cases.

* More and more Perl 6 is implemented on the magical, mythical self-hosting Perl 5. Perl 5 should slowly morph into a reasonable subset of Perl 6. XS back compat should be broken for cases where the macros can't be adapted to work, which is about any time magic or anything severe is used. Modules that depend heavily on the core do important things and would be moved to core -- autobox, Coro, Padwalker, etc.


The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Hmm, funny these things are all on my wishlist too, although I just didn't know it until you detailed them :)

    I would love to see static anlysis & type inference in Perl not just for optimization's sake, but for type-check style "safety" (your module is a definite starting point). And of course the ability to extend Perl with Perl on a level beyond what can already be done would be awesome.

    Very nice post.

    - Stevan