http://qs321.pair.com?node_id=247167


in reply to How is a perl program processed ?

Well, what's compilation for you? Any good interpreted language make a parse of the code, create a bytecode, optimize it, and than run the code. You can see that for Perl, Phyton, Java (yes a .class is just a bytecode), etc...

When the bytecode is created the code is optimized, numbers will be calculated (like 1024*8 to 8192), quoted strings will be parsed, etc... And this is very important to can run nice and easy the code.

About the regex. Well, why parse and create for each regex? In the bytecode stage all the regex are parsed and created, and similar regex will use the same compiled regex. Note that regex is not a simple thing to do, and anything that can get speed is welcome!

I think that the best way to differ real compiled programs to interpreted, is the creation of binarys codes or not. A real binary code will have machine codes, that will be executed by the OS to work with the CPU instructions.

The definition of compilation can't tell you if is a interpreted program:
Compile: To put together, to construct, to build... To put together in a new form...

Just to remember some assembler. This code in C, when is compiled, is converted to Assembler fisrt: 

  ## C:
  a = b + c + d ;

  ## Assembler:
  ADD a , b , c
  ADD a , a , d

[download]
The ADD is a CPU instruction (based on MIPS). But in the end everything is interpreted, if you think that CPU instructions are a language. ;-P

About Perl supposed to be doing interpretation. Well, Perl don't follow any theorie/philosophy/concept just by the theorie/philosophy/concept. This is why the Perl interpreter is the faster and with the best memory management that exist.

The famous phrase:
"Perl is designed to make the easy jobs easy and the hard jobs possible."
-Larry Wall

Graciliano M. P.
"The creativity is the expression of the liberty".

Replies are listed 'Best First'.
Re: Re: How is a perl program processed ?
by dakkar (Hermit) on Apr 01, 2003 at 08:11 UTC

    A teacher of mine said that an interpreter has a signature of:

    (P × D) ⇀ D

    Instead a compiler has a signature of:

    P ⇀ D ⇀ D

    Where P is the domain of programs, and D is the domain of data.

    So perl has a signature of the first kind: you give it the source and the data at the same time. cc, on the other hand, has asignature of the second kind: you give it only the source, and it produces another program, which is a function from data to data.

    So much for theory

    In practice, traditionally an interpreter has worked in a "miopic" way, looking at a single line (or even less) of code at a time; a compiler instead has always looked "at the big picture", swallowing the entire source at once, looking for problems and inconsistencies.

    So, in this way, Perl is a compiler.

    And on a sidenote, C is compiled to machine language, not assembly. Assembly is compiled to machine language by an assembler...

    -- 
        dakkar - Mobilis in mobile
[reply]
      There's no sharp border between a compiler and and an interpreter. As you said, we often think of a compiler that takes the entire source code, and produces something else (typically, before running it), while an interpreter just looks at a small chunk of the source at a time, and executes that before carrying on.

      But compilers typically produce output that's being "interpreted". Machine code is basically "interpreted". And a language that has the ability to use "eval", can defer most of its "compilation" to runtime, and have it compiled one chunk at a time.

      I usually call a program that takes data in one format and produces equivalent data in another format a compiler. That means that 'gcc' is a compiler. But also 'dvips'. And perhaps parts of 'perl' as well, although the other format is only used internally.

      Abigail

[reply]

In Section Seekers of Perl Wisdom