Re^4: Perl 5 Optimizing Compiler, Part 9: RPerl.org & The Low-Magic Perl Commandments

[Will_the_Chill]

Dave,

You win another brownie point! I did not strongly enough ban non-variable non-slice lvalues, the commandments have been updated yet again thanks to your sharp eye!

LMPC #20. Thou Shalt Use Scalars, Arrays, Hashes, Filehandles, & Mundane Lvalues (Variables & Slices)

LMPC #21. Thou Shalt Not Use Typeglobs, Code References, Weak References, Or Magic Lvalues (Builtins, Non-Variables, Non-Slices, etc)

I must disagree with your comment about not-using-other-people's-maybe-tied-vars, commandment #3 says not to use non-PBP code, which includes code-with-tied-vars written by either you _or_ somebody else.

LMPC #3. Thou Shalt Not Use ... Non-PBP Code ...

My previous post (Perl 5 Optimizing Compiler, Part 8: The Book Of RPerl) was made over 6 weeks ago, surely that's been enough time for your strength to return? ;-)

I think your questions about RPerl are generally answered in The RPerl FAQ, clearly linked at the very top of the Part 9 original post. Still, to answer your question specifically, the point of RPerl is to create an optimizing Perl 5 compiler. To achieve this, RPerl will initially remove all magic from Perl 5 and create a "restricted" (like RPython) subset of the Perl 5 language which can be compiled directly to C/C++ code, which is itself 100% compatible with, and equivalent to, the original Perl 5 code. This is implemented in RPerl by generating specially-crafted C/C++ code that can be fed through Inline::C(PP) and tie back into Perl 5 via XS. Once we have RPerl working with low-magic Perl 5 code, we can start selectively adding back in the magic components 1-by-1, retaining the ability to turn off all magic at any time to keep the pure speed boost of low-magic compiled code. As I've stated already, you can mix compiled low-magic code with normal non-compiled high-magic code.

To quote myself from my most immediately previous response to you, "Note, my use of the term 'magic' refers to both the specific so-named magic bits attached to Perl data structures, as well as Perl's wacky/weird/complex operations in general." You're right in pointing out that the magic bits attached to the Perl data structures are only 1 part of the "magic" that needs to be turned off to achieve massive performance benefits. This is why there are more commandments under the "Operations" section than the "Data" section.

Perling,
~ Will

[dave_the_m]

(As it happens I did read the FAQ)

Since "magic" has a specific meaning within perl, can I suggest you use some other term?

To expand upon the RPython issue: RPython is not intended for writing general code; its intended specifically only for writing interpreters; within that limited use case, it makes sense to have a language similar to python, but highly restricted (in particular, static typing).

In the RPerl case, you seem to be targetting it towards general code, where you mark limited sections of your code as targets for optimisation. The problem seems to me that your restrictions are so severe (no regexes!!!!) that virtually no real-life code is amenable to any speed-ups.

Dave.

[Will_the_Chill]

Dave,

I appreciate your suggestion of not expanding the already-specific meaning of the term "magic" in relation to Perl. Do you have any suggestions? Maybe something magic-like, such as "mystical" or "charmed" or "miracle"?

I am very interested in expanding upon the RPython issue. :) Like RPython, RPerl can definitely be used to write interpreters. In fact, I see that as a possible huge win in the future. Like RPython, RPerl (initially, at least) also requires static typing.

To a degree you are correct, I am targeting RPerl toward general-use code in the long-term. In the short-term, RPerl will most immediately be useful for hot code, such as a computational kernel which is already separated from other code and can safely be re-written into "low-magic" (barring better terminology) form.

I think the deeper issue is the Perl community's (perhaps unhealthy) love affair with high-magic code, and even medium-magic code. This is echoed in your statement that "Perl without its internal 'magic' implementation is essentially no longer Perl." However, have no fear, lover of magic! As I've stated repeatedly:

1. We can mix low-magic code with high-magic code.

AND

2. We can add back in all the high-magic components after we've got RPerl v1.0 working with the low-magic components.

Specifically, regular expressions will likely be the VERY FIRST THING added back into RPerl after v1.0 is done. I know how much everybody loves their regexes.

Perling,
~ Will

[Anonymous Monk]

I propose mugic pronounced like mujic (if you type mujic into eSpeak) , cause you sip from a mug, a magical musical brew, just in case its ick or the answer is mu