Re: Disadvantage of not supporting pthreads in perl and how perl overcomes?

[sundialsvc4]

This node falls below the community's threshold of quality. You may see it by logging in.

[shmem]

Now, Perl is an interpreted environment

Let's draw a line here. The term interpreted only makes sense if it is used to set the so termed apart from not interpreted, which in my book reads as compiled.

In a broader sense, any reception of something emitted is interpretation, succinctly put by Rolf Schott:

Expressing a thought, even oneself is beginning to misunderstand it.

Reading something, a book, a note on PerlMonks, an article on the web, what we experience is our immediate interpretation of it, not the authors notion of the issued. This is due to the fact that none of us is capable to utter ourselves in a way which is absolutely congruent to what we are, and unable to live the entirety of our kin except perhaps in deepest love.

Back to interpreted in the computational notion. The bash shell is a command line interpreter (which can get its lines from a file), and it gobbles up as much input as needed to execute something (or to set up delayed execution of interpreted expressions, called functions(){}) and executes that until an error is encountered or EOF is met.

Perl is different. It compiles its source and replaces each token of its input with opcodes, pointers to char arrays, integers, function and return addresses and so on, and only if that transformation succeeds without errors, it runs the established internal representation of the source read, sporting parameter stack, branches, return addresses et cetera, like a baroque forth engine.

Bottom line: perl programs are not interpreted. They are compiled and run on the fly. What is run are not interpreted commands, but a chain of (pre-)compiled C functions.

[Anonymous Monk]

This may be superfluous at this point in time... but, I feel the need to set the record straight on this for those who are newer to the fields of languages and interpreters versus compilers and etc.

BOTTOM LINE: Any language that is not "translated" (aka compiled) into native CPU/machine opcodes is "interpreted"

Java is a language. It is actually interpreted, too. It has the Java VM that is basically an artificial CPU with its own opcodes. JAR files are actually hybrid ZIP files. In all actuality, Java was Sun's attempt to revive itself hoping to create (or subvert) a market for it's now mostly-defunct RISC processors that were drowning in a predominately Intel/Motorola world. (FYI, Java's birthplace was in Pascal and Modula-2/3 from Nik Wirth -- not Smalltalk.)

Perl is a language. It executes in a well-defined interpreted environment (interpreter) that does NOT CONSIST OF MACHINE CODE (aka processor opcodes). Perl's YACC specification reduces to mnemonics that are equivalent to opcodes -- but are not , for example, Intel CPU opcodes.

C is a language. It is preprocessed and compiled down to machine opcodes (Intel or whatever). But, if you wanted to, you could probably generate a compiler to reduce to Java Virtual CPU opcodes, too.

Larry Wall/Perl did not create a separate standalone Java-like Virtual CPU (aka VM) for Perl. (But, it looks like they are trying on Perl 6).

Virtual CPUs (VM) are the ultimate vehicle for malware. You can write a malware once; compile it once; and run it anywhere, too! People dumb enough to keep it running in the SysTray are an accident waiting to happen. ;)

Lex (at least at some point in the past) and YACC were used to create Perl, Bash, and a host of other languages.

Lex and YACC are written in C. Google's former-CEO Eric Schmidt's claim to fame, before becoming a politician, was his work on Lex as an understudy to the great Mike Lesk.

Perl is cool. It's the result of incorporating the core features/capabilities of YACC into a super-versatile text processing language. Any Perl program can become a Turing Machine. Ingenious. (I don't know of any other language that has ever accomplished this feat)

However, because of this interpreter, threading/MP is a little more difficult, unpredictable, and memory-hungry. Careful planning is required.

[Anonymous Monk]

You'd need to provide a good formal definition first, to "set the record straight."

AFAIK the key difference between an interpreter and a compiler is that the latter is no longer required during program execution. The source is already translated, and executes in another domain.

LLVM for instance translates C sources first into IR (intermediate representation), and can output bitcode if so desired. Compiling to target architecture is "lowering" in llvm parlance. But you can run bitcode directly with lli, either interpreted or JIT-compiled.

Anyway, I just wanted to point out that the term compiling is more abstract and does not necessarily involve the notion of "native machine code". Turtles all the way.