Editing PL/I (section)

===Implementation issues===
Though the language is easy to learn and use, implementing a PL/I compiler is difficult and time-consuming. A language as large as PL/I needed subsets that most vendors could produce and most users master. This was not resolved until "ANSI G" was published. The compile time facilities, unique to PL/I, took added implementation effort and additional compiler passes. A PL/I compiler was two to four times as large as comparable Fortran or COBOL compilers, and also that much slower—supposedly offset by gains in programmer productivity. This was anticipated in IBM before the first compilers were written.<ref name="characteristics1978"/>

Some argue that PL/I is unusually hard to parse.<ref>The compiler cannot tell whether a statement is a declaration or a multiple assignment statement until encountering the "=" of the assignment or ";" of the DECLARE—which can be several lines later. The fact that DECLARE/DCL were not reserved is the proximate cause in this example{{snd}} consider the fragment <code>DECLARE(I,J,K),L= </code> vs <code>DECLARE(I,J,K),L;</code>.</ref> The PL/I ''keywords'' are not reserved so programmers can use them as variable or procedure names in programs. Because the original PL/I(F)  compiler attempts ''auto-correction'' when it encounters a keyword used in an incorrect context, it often assumes it is a variable name. This leads to "cascading diagnostics",<ref name=CasD>{{cite web
|url=https://atlas.ion.uwplatt.edu/bitbucket/projects/SB/repos/buildscripts/raw/DotnetCore/sdk/NuGetFallbackFolder/microsoft.codeanalysis.csharp/2.3.1%2Flib%2Fnetstandard1.3%2FMicrosoft.CodeAnalysis.CSharp.xml?at=b1dc21b912b5570ba5f46c5733a261496f6cbf7d
|title=Microsoft.CodeAnalysis.CSharp A Binder converts names
}}{{Dead link|date=May 2020 |bot=InternetArchiveBot |fix-attempted=yes}}</ref> a problem solved by later compilers.

The effort needed to produce good object code was perhaps underestimated during the initial design of the language. [[Program optimization]] (needed to compete with the excellent program optimization carried out by available Fortran compilers) is unusually complex owing to [[Side effect (computer science)|side effects]] and pervasive problems with [[Aliasing (computing)|aliasing]] of variables. Unpredictable modification can occur asynchronously in [[Exception handling|exception handlers]], which may be provided by "{{tt|ON}} statements" in (unseen) callers. Together, these make it difficult to reliably predict when a program's variables might be modified at runtime. In typical use, however, user-written error handlers (the {{tt|ON}}-unit) often do not make assignments to variables. In spite of the aforementioned difficulties, IBM produced the PL/I Optimizing Compiler in 1971.<ref name=OptPLI.1971>{{cite web
 |url=https://www.computer.org/csdl/magazine/an/2013/04/man2013040018/13rRUxBrGiQ
 |title=Early Language and Compiler Developments at IBM Europe
 |author=A. Endres |year=2013}}</ref>

PL/I contains many rarely used features, such as [[Computer multitasking|multitasking]] support (an IBM extension to the language) which add cost and complexity to the compiler, and its co-processing facilities require a multi-programming environment with support for non-blocking multiple threads for processes by the [[operating system]]. Compiler writers were free to select whether to implement these features.

An undeclared variable is, by default, declared by first occurrence—thus misspelling might lead to unpredictable results. This  "implicit declaration" is no different from FORTRAN programs. For PL/I(F), however, an attribute listing enables the programmer to detect any misspelled or undeclared variable.