Re^3: Perl 5 Optimizing Compiler, Part 15: RPerl v1.2 Kickstarter Now Live

For me, personally, the "Low-Magic Perl Commandements" do not really read like a technical list of things that are supported or unsupported. I think it would fare better with a preamble of "These are the features that you will need to write your code to such that RPerl can support it". But reinterpreting them as a technical list of things that are supported or unsupported, there are some commandements that will hinder RPerl to become ever usable for me:

17. THOU SHALT NOT:Use Dynamic-Type Data, Auto-Vivification, Or Tied Variables

This means that DBI and DBD::* are right out of the window without major retooling of DBI and all related code not to rely on tie'd hashes.

19. THOU SHALT NOT: Use Private Dynamic-Scope (“local”), Private Persistent Lexical-Scope (“state”), Global, Or Package Variables (“our”)

Of course, global variables have their place and are highly useful, for example as global defaults. Whenever there is a lexical variable in global scope, that lexical variable should be a global variable in case somebody really wants to override it. Maybe some arguments as to why avoiding local and global variables would be good. For example, such variables make reasoning about value escape much, much harder and preclude some optimizations. But taken as an absolute, they are not good recommendations.

21. THOU SHALT NOT: Use Typeglobs, Code References, Weak References, Or Magic Lvalues (Builtins, Non-Variables, Non-Slices, etc)

I'm not sure what the technical gain here is. But without code references every dispatch table flies out of the window. Without weak references you can't really implement trees or doubly-linked lists or other data structures in a way that enables the reference-counted memory management to clean up such structures automatically.

23. THOU SHALT NOT: Use Aliased, Non-Descriptive, Special ($1, $a, %ENV, %SIG, etc), Or Punctuation Variables ($_, @_, %!, $@, $$, etc)

What is the technical reason for RPerl to not allow access to those variables?

35. THOU SHALT NOT: Use Taint Mode

This is a WTF as written. Taint mode relies heavily on magic, so I understand the technical reason for this but it needs some more elaboration. The corresponding "THOU SHALT" of "34. Use Secure Platforms & Trusted Data" moves this recommendation into rainbow unicorn country. If we're able to make wishes come true, why doesn't rule 34 say "THOU SHALT WRITE FAST,SHORT,CORRECT AND EASILY UNDERSTOOD PROGRAMS" and replace all preceding and following rules instead?

I find the reliance on PBP and Perl::Critic makes it an instant turn-off because much of PBP isn't that great a practice without further review and adaption to the situation at hand. This is recommended on the first pages of PBP, but I found people referring to PBP always took PBP as literal gospel instead of reviewing the recommendations before applying them.

Comment on Re^3: Perl 5 Optimizing Compiler, Part 15: RPerl v1.2 Kickstarter Now Live Select or Download Code

Replies are listed 'Best First'.
Re^4: Perl 5 Optimizing Compiler, Part 15: RPerl v1.2 Kickstarter Now Live by LanX (Saint) on Sep 27, 2015 at 22:23 UTC
> But reinterpreting them as a technical list of things that are supported or unsupported, there are some commandements that will hinder RPerl to become ever usable for me: Well the question seems to be, if a compatibility mode would be offered, to run "impure" code at "normal" speed. Otherwise I have problems to see the manpower coming to port old CPAN modules. But if `use types` really means that variables must be typed, together with all other restrictions, this would just be a C (or C++) with Perlish syntax (and consequently a different language) Which isn't necessarily useless. I could still imagine this to be useful as an inline language ( `Inline::RPerl` ) to avoid XS for inner loops where performance matters. (which would also solve the compatibility issue) Rather not as a replacement for Perl in total... > For me, personally, the "Low-Magic Perl Commandements" do not really read like a technical list of things that are supported or unsupported. This religious approach is really disturbing ... Cheers Rolf _{(addicted to the Perl Programming Language and ☆☆☆☆ :) Je suis Charlie!}	[reply] [d/l] [select]
Re^5: Perl 5 Optimizing Compiler, Part 15: RPerl v1.2 Kickstarter Now Live by Corion (Patriarch) on Sep 28, 2015 at 08:04 UTC
But if use types really means that variables must be typed, together with all other restrictions, this would just be a C (or C++) with Perlish syntax (and consequently a different language) Which isn't necessarily useless. I could still imagine this to be useful as an inline language ( Inline::RPerl ) to avoid XS for inner loops where performance matters. Yeah, the commandements reduce Perl to a managed-memory C without function pointers. As you say, it isn't useless if you want to avoid C and XS.	[reply]
Re^6: Perl 5 Optimizing Compiler, Part 15: RPerl v1.2 Kickstarter Now Live by LanX (Saint) on Sep 28, 2015 at 12:48 UTC
From the FAQ Q: How does RPerl work? A: The input to the RPerl compiler is low-magic Perl 5 source code. RPerl converts the low-magic Perl 5 source code into C++ source code using Perl and/or C++ data structures. Inline::CPP converts the C++ source code into XS source code. Perl's XS tools and a standard C++ compiler convert the XS source code into machine-readable binary code, which can be directly linked back into normal high-magic Perl 5 source code. The output of the RPerl compiler is fast-running binary code that is exactly equivalent to, and compatible with, the original low-magic Perl 5 source code input. The net effect is that RPerl compiles slow low-magic Perl 5 code into fast binary code, which can optionally be mixed back into high-magic Perl apps. Now I remember Reini talking about it. update Though I'm not sure how the "mix back" is supposed to work. IIRC from Reini's talk, something like `Inline::Rperl` is not intended. Cheers Rolf _{(addicted to the Perl Programming Language and ☆☆☆☆ :) Je suis Charlie!}	[reply] [d/l]
Re^5: Perl 5 Optimizing Compiler, Part 15: RPerl v1.2 Kickstarter Now Live by Anonymous Monk on Sep 27, 2015 at 23:39 UTC
LanX: This religious approach is really disturbing ... funny, look around "Canon", you've been doing it for years	[reply]
Re^4: Perl 5 Optimizing Compiler, Part 15: RPerl v1.2 Kickstarter Now Live by stevieb (Canon) on Sep 27, 2015 at 13:22 UTC
Am I the only one here who read the list of DO NOTs Corion posted and thought "the only script I've ever written that doesn't rely on one (or more likely some or even most) of those was my first one, where all it did was `print "hello, world!";`"? I don't have time to read through all the docs, but if any of those things remove the benefit of RPerl, then it'll never be useful to me. Is there something I don't know based on not having read the full documentation?	[reply] [d/l]

update