[Israel.pm] perl program life cycle

Gaal Yahas gaal at forum2.org
Wed Jun 15 21:26:43 PDT 2005


On Tue, Jun 14, 2005 at 10:57:34AM +0300, Sagiv Barhoom wrote:
> Hey all,
> I am reading about the an article "/o is dead, long live qr//!" from the perlmonk site:
> http://perlmonks.org/index.pl?node_id=269035
> 
> I read a line which I do not understand:
> "...The qr// operator (defined in perlop) allows you to have $HUGE_REGEX be precompiled during the script compilation time (instead of runtime - this might be important for mod_perl users) and potentially greater control over expression changes. ..."
> 
> As far as I know, Perl does not compile the code rather interpert the text.
> Can any one refer me to a very simple explanation  about Perl program life cycle?

There are a few subtleties involved in this distinction. :-)

But first of all regarding the perlmonks article: the author was talking
specifically about using qr// with a string *without interpolation*,
which perl is clever enough to detect at compile time and turn immediately
into a compiled regexp. qr// in general of course *has* to be able to
happen at runtime as well, because otherwise you wouldn't be able to do
things like qr/My name is \Q$name/, or the useful

     $small_re1 = qr/....../;
     $small_re2 = qr/........./;

     $big_re = qr/...(?:$small_re1)+?..$small_re2/;

-- these are techniques to build big regexps out of small ones that are
good practices and which indeed work!


Ofer's reply is quite correct: when you start a perl program, "as much
of it as possible" is compiled immediately, but the thing that does the
compilation stays resident for the chance you'd need it later. The main
difference between this and, say, Java, is that there's no useful way to
store the thing that's the result of compilation on disk files, so you
*must* carry around the compiler wherever there's a perl program (in
approximate Java terms, you always need a jdk, not just a jre).

This of course isn't just some sort of oversight: perl is a dynamic
language so you're *encouraged* to create parts of your program at
runtime. For example, you can not only load but also generate classes
on-the-fly. But once again, it isn't like the old BASIC systems or
a shell script where if you enter a loop ten times each statement is
compiled over and over again. But we still call perl the "interpreter"
or "compiler", pretty much interchangebly, because it's somewhere on
the middle of the spectrum.

Then again, the fact that there's no clear conceptual distinction in the
perl (1..5) interpreter between intermediate representation and what it
is the lower level runs does mean that you have an op tree, and you have
to have someone which isn't the actual CPU *run* that op tree. In Perl6
(you saw this coming :-) this will be fixed: the perl *compiler* will
generate Parrot ops and not evaluate them itself. This is cleanliness of
design; in Pugs this means you actually have a choice of whether to
compile to parrot or something else. See Autrijus' recent journal
entries for more details: http://use.perl.org/~autrijus/journal/ .

-- 
Gaal Yahas <gaal at forum2.org>
http://gaal.livejournal.com/



More information about the Perl mailing list