Perl | Part 3
Perl Applications
Perl has many and varied applications, thanks to the availability of many standard modules and third parties.
It has been used since the early days of the Web to write scripts (scripts) CGI. It is one of the “three Ps” (Perl, Python and PHP), which are the most popular languages for creating Web applications, and is an integral component of the popular LAMP solution stack for web development. Large projects written in Perl are Slash, IMDb and UseModWiki, a Wiki engine. Many high-traffic websites such as Amazon.com and Ticketmaster.com use Perl extensively.
Perl is often used as a glue language, tying together systems and interfaces that were not specifically designed to interoperate, and for “data munging”, converting or processing large amounts of data for tasks such as creating reports. In fact, these strengths are intimately linked. Their combination makes perl a popular general-purpose tool for system administrators, especially in small programs that can be written and executed in a single command line.
Perl is also widely used in finance and bioinformatics, which is prized for its rapid development of applications such as deployment and the ability to handle large volumes of data.
Perl Implementation
Perl is implemented as an interpreter, written in C, together with a large collection of modules, written in Perl and C. The source distribution is, in 2005, 12 MB when packaged and compressed into a tar file. The shell has 150,000 lines of C code and compiled into an executable file of 1 MB on typical machine architectures. Alternatively, the interpreter can be compiled as a library and embedded in other programs. There are nearly 500 modules in the distribution, comprising 200,000 lines of Perl and an additional 350,000 lines of C code Much of the C code in the modules consists of character encoding tables.
The interpreter has an object-oriented architecture. All elements of the Perl language-scalars, arrays, hashes, references to code, file handles-are represented in the interpreter by C structs Operations on these structures are defined by a large collection of macros, typedefs and functions; this is the Perl C API. The Perl API can be bewildering to the uninitiated, but its entry points follow a consistent naming scheme that helps those who use it.
The execution of a Perl program can be divided broadly into two phases: compile time and runtime. At compile time the interpreter parses the program text into a syntax tree. At runtime, execution follows the tree. The text is parsed only once and is optimized syntax tree before execution, so that the execution phase is relatively efficient. Syntax tree optimizations at compile time include simplification of constant expressions and context propagation and optimization of stray bits of code. However, the phases of compilation and execution can be nested: a BEGIN block is executed at compile time, whereas an eval function initiates compilation during an execution. Both operations are implicit in others, notably, the use clause that loads libraries, known in Perl as modules, implies a BEGIN block.
Perl is a dynamic language and has a context-sensitive grammar can be affected by the code executed during an execution phase intermediate. So Perl can not be parsed by a direct application of lexical analyzer / parser Lex / Yacc. Instead, the interpreter implements its own lexer, which coordinates with a modified GNU bison parser resolves the ambiguities of language. It has been said that “only perl can parse Perl”, meaning that only the Perl interpreter (perl) can parse the Perl language (Perl). The reason for this is attested by the persistent imperfections of other programs that undertake the task of parsing Perl as code analyzers and auto-indenters, which have to deal not only with the many ways of expressing unequivocal syntactic constructions, but also with the fact that Perl also can not generally be parsed without being executed.
Maintaining the Perl interpreter, over the years, has become increasingly difficult. The core has been in continuous development since 1994. The code has been optimized for performance at the expense of simplicity, clarity, and presents strong internal interfaces. New features have been added, keeping still, virtually complete backward compatibility with earlier versions. The size and complexity of the interpreter is a barrier for developers who want to work on it.
Perl is distributed with some 120,000 functional tests. These run as part of normal construction and extensively to the interpreter and its core modules. Perl developers rely on functional tests to ensure that changes in the interpreter do not introduce errors, conversely, the Perl users who see the interpreter passed functional tests on your system may have a high degree of confidence that it is working properly.
There is no written specification or standard for the Perl language and no plans to create one for the current version of Perl. There has always been only one implementation of the interpreter. This interpreter, together with functional tests, is the de-facto language specification.
Continued…


