Editing Perl (section)

=== Implementation ===

No written [[Formal specification|specification]] or standard for the Perl language exists for Perl versions through Perl 5, and there are no plans to create one for the current version of Perl. There has been only one implementation of the interpreter, and the language has evolved along with it. That interpreter, together with its functional tests, stands as a ''de facto'' specification of the language. Perl 6, however, started with a specification,<ref>{{cite web |url=http://www.perl6.org/specification |title=Perl 6 Specification |access-date=2011-01-27 |publisher=The Perl 6 Project |archive-date=December 2, 2009 |archive-url=https://web.archive.org/web/20091202073507/http://www.perl6.org/specification/ |url-status=live}}</ref> and several projects<ref>{{cite web |url=http://www.perl6.org/compilers/ |title=Perl 6 Compilers |access-date=2011-01-27 |publisher=The Perl 6 Project |archive-date=December 2, 2009 |archive-url=https://web.archive.org/web/20091202073302/http://www.perl6.org/compilers/ |url-status=live}}</ref> aim to implement some or all of the specification.{{Citation needed|date=December 2020}}

Perl is implemented as a core interpreter, written in C, together with a large collection of modules, written in Perl and C. {{As of|2010}}, the interpreter is 150,000 lines of C code and compiles to a 1&nbsp;MB executable on typical machine architectures. Alternatively, the interpreter can be compiled to a link 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).{{Citation needed|date=December 2020}}

The interpreter has an object-oriented architecture. All of the elements of the Perl language—scalars, arrays, hashes, coderefs, [[file handle]]s—are represented in the interpreter by [[struct (C programming language)|C structs]]. Operations on these structs are defined by a large collection of [[Macro (computer science)|macros]], [[typedef]]s, and functions; these constitute the Perl C [[application programming interface|API]]. The Perl API can be bewildering to the uninitiated, but its entry points follow a consistent [[naming scheme]], which provides guidance to those who use it.{{Citation needed|date=December 2020}}

The life of a Perl interpreter divides broadly into a compile phase and a run phase.<ref>A description of the Perl 5 interpreter can be found in ''Programming Perl'', 3rd Ed., chapter 18. See particularly page 467, which carefully distinguishes run phase and compile phase from [[Run time (program lifecycle phase)|run time]] and [[compile time]]. Perl "time" and "phase" are often confused.</ref> According to Aluín et al., "Perl cannot be parsed by a straight Lex/Yacc lexer/parser combination. Instead, the interpreter implements its own lexer, which coordinates with a modified GNU bison parser to resolve ambiguities in the language."<ref>{{Cite book |last1=Abuin |first1=Jose M. |last2=Pichel |first2=Juan C. |last3=Pena |first3=Tomas F. |last4=Gamallo |first4=Pablo |last5=Garcia |first5=Marcos |chapter=Perldoop: Efficient execution of Perl scripts on Hadoop clusters |date=2014 |title=2014 IEEE International Conference on Big Data (Big Data) |chapter-url=https://ieeexplore.ieee.org/document/7004303 |publisher=IEEE |pages=766–771 |doi=10.1109/BigData.2014.7004303 |isbn=978-1-4799-5666-1}}</ref>

Most of what happens in Perl's compile phase is compilation, and most of what happens in Perl's run phase is execution, but there are significant exceptions. Perl makes important use of its capability to execute Perl code during the compile phase. Perl will also delay compilation into the run phase. The terms that indicate the kind of processing that is actually occurring at any moment are ''compile time'' and ''run time''. Perl is in compile time at most points during the compile phase, but compile time may also be entered during the run phase. The compile time for code in a string argument passed to the <code>[[eval]]</code> built-in occurs during the run phase. Perl is often in run time during the compile phase and spends most of the run phase in run time. Code in <code>BEGIN</code> blocks executes at run time but in the compile phase.<!-- NOTE TO EDITORS: There is something missing in the preceding sentence -- for one thing, a comma before the conjunction. The sentence might reasonably read 'Code in BEGIN blocks executes NOT at run time, but in the compile phase,' but is that what the author intended? -->

At compile time, the interpreter parses Perl code into a [[Abstract syntax tree|syntax tree]]. At run time, it executes the program by [[Tree traversal|walking the tree]]. Text is parsed only once, and the syntax tree is subject to optimization before it is executed, so that execution is relatively efficient. Compile-time optimizations on the syntax tree include [[constant folding]] and context propagation, but [[peephole optimization]] is also performed.<ref>{{Cite web|title=perlguts - Introduction to the Perl API - Perldoc Browser|url=https://perldoc.perl.org/perlguts#Compile-pass-3:-peephole-optimization|access-date=2022-01-24|website=perldoc.perl.org}}</ref>

Perl has a [[Turing-complete]] [[formal grammar|grammar]] because parsing can be affected by run-time code executed during the compile phase.<ref>{{cite web |last=Schwartz |first=Randal |author-link=Randal L. Schwartz |title=On Parsing Perl |url=http://www.perlmonks.org/index.pl?node_id=44722 |access-date=2007-01-03 |archive-date=September 27, 2007 |archive-url=https://web.archive.org/web/20070927000827/http://www.perlmonks.org/index.pl?node_id=44722 |url-status=live}}</ref> The code cannot be parsed by a straight [[Lex programming tool|Lex]]/[[Yacc]] [[Lexical analysis|lexer]]/[[parser]]. To resolve ambiguities in the language the interpreter must implement its own lexer to coordinate with a modified [[GNU bison]] parser.<ref>{{Cite book |last1=Abuin |first1=Jose M. |last2=Pichel |first2=Juan C. |last3=Pena |first3=Tomas F. |last4=Gamallo |first4=Pablo |last5=Garcia |first5=Marcos |chapter=Perldoop: Efficient execution of Perl scripts on Hadoop clusters |date=2014 |title=2014 IEEE International Conference on Big Data (Big Data) |chapter-url=https://ieeexplore.ieee.org/document/7004303 |publisher=IEEE |pages=766–771 |doi=10.1109/BigData.2014.7004303 |isbn=978-1-4799-5666-1}}</ref>

It is often said that "Only perl can parse Perl",<ref>{{cite web |url=ftp://ftp.ora.com/pub/labs/tpj/tpj2.pdf |title=The Perl Journal #19/9.26 |access-date=2011-02-04 |archive-url=https://web.archive.org/web/20200227002839/ftp://ftp.ora.com/pub/labs/tpj/tpj2.pdf |archive-date=2020-02-27 |url-status=dead |publisher=[[O'Reilly Media]] }}</ref> meaning that only the Perl interpreter (''<code>perl</code>'') can parse the Perl language (''Perl''), but even this is not, in general, true. Because the Perl interpreter can simulate a Turing machine during its compile phase, it would need to decide the [[halting problem]] in order to complete parsing in every case. It is a longstanding result that the halting problem is undecidable, and therefore not even Perl can always parse Perl. Perl makes the unusual choice of giving the user access to its full programming power in its own compile phase. The cost in terms of theoretical purity is high, but practical inconvenience seems to be rare.<ref>{{cite web
 |url=http://blogs.perl.org/users/jeffrey_kegler/2011/10/perl-and-parsing-11-are-all-perl-programs-parseable.html
 |title=Perl and Parsing 11: Are all Perl programs parseable? |last=Kegler |first=Jeffrey |date=October 7, 2011 |access-date=October 25, 2022
 |quote=... we seem to be giving up absolutely nothing. Nobody has ever been able to show a practical downside}}</ref>

Other programs that undertake to parse Perl, such as [[Static program analysis|source-code analyzers]] and [[Indent style|auto-indenters]], have to contend not only with ambiguous [[Language construct|syntactic constructs]] but also with the [[Recursive language|undecidability]] of Perl parsing in the general case. [[Adam Kennedy (programmer)|Adam Kennedy]]'s PPI project focused on parsing Perl code as a document (retaining its integrity as a document), instead of parsing Perl as executable code (that not even Perl itself can always do). It was Kennedy who first conjectured that "parsing Perl suffers from the 'halting problem',"<ref>{{cite web |url=https://metacpan.org/module/PPI |title=PPI—Parse, Analyze and Manipulate Perl (without perl) |last1=Kennedy |first1=Adam |year=2006 |publisher=[[CPAN]] |access-date=September 16, 2013 |archive-date=September 3, 2013 |archive-url=https://web.archive.org/web/20130903091241/https://metacpan.org/module/PPI |url-status=live}}</ref> which was later proved.<ref>{{cite journal |title=Rice's Theorem |journal=The Perl Review |volume=4 |issue=3 |pages=23–29 |date=Summer 2008}} and {{cite journal |title=Perl is Undecidable |journal=The Perl Review |volume=5 |pages=7–11 |date=Fall 2008}}, available online at {{cite web |url=http://www.jeffreykegler.com/Home/perl-and-undecidability |title=Perl and Undecidability |last1=Kegler|first1=Jeffrey |access-date=January 4, 2009 |archive-date=August 17, 2009 |archive-url=https://web.archive.org/web/20090817183115/http://www.jeffreykegler.com/Home/perl-and-undecidability |url-status=live}}</ref>

Perl is distributed with over 250,000 [[Functional testing|functional tests]] for core Perl language and over 250,000 functional tests for core modules. These run as part of the normal build process and extensively exercise the interpreter and its core modules. Perl developers rely on the functional tests to ensure that changes to the interpreter do not introduce [[software bug]]s; further, Perl users who see that the interpreter passes its functional tests on their system can have a high degree of confidence that it is working properly.{{Citation needed|date=December 2020}}