Editing BCPL (section)

==Design==
{{More citations needed section|date=January 2017}}

BCPL was designed so that small and simple compilers could be written for it; reputedly some compilers could be run in 16 [[kilobyte]]s. Furthermore, the original compiler, itself written in BCPL, was easily portable. BCPL was thus a popular choice for [[bootstrapping (compilers)|bootstrapping]] a system.{{Citation needed|date=January 2017}}  A major reason for the compiler's portability lay in its structure. It was split into two parts: the front end parsed the source and generated O-code, an [[intermediate language]]. The back end took the O-code and translated it into the machine code for the target machine. Only {{frac|5}} of the compiler's code needed to be rewritten to support a new machine, a task that usually took between 2 and 5 [[man-month|person-month]]s. This approach became common practice later (e.g. [[Pascal (programming language)|Pascal]], [[Java (programming language)|Java]]).

The language is unusual in having only one [[data type]]: a [[Word (computer architecture)|word]], a fixed number of bits, usually chosen to align with the same platform architecture's machine word and of adequate capacity to represent any valid storage address. For many machines of the time, this data type was a 16-bit word. This choice later proved to be a significant problem when BCPL was used on machines in which the smallest addressable item was not a word but a [[byte]] or on machines with larger word sizes such as 32-bit or 64-bit.{{Citation needed|date=January 2017}}

The interpretation of any value was determined by the operators used to process the values. (For example, <code>+</code> added two values together, treating them as [[integer]]s; <code>!</code> indirected through a value, effectively treating it as a pointer.) In order for this to work, the implementation provided no [[type checking]].

The mismatch between BCPL's word orientation and [[Byte addressing|byte-oriented]] hardware was addressed in several ways. One was by providing standard library routines for packing and unpacking words into byte strings. Later, two language features were added: the bit-field selection operator and the infix byte indirection operator (denoted by <code>%</code>).<ref>{{Cite web |title=Clive Feather on CPL and BCPL |url=https://www.lysator.liu.se/c/clive-on-history.html |access-date=2024-03-01 |website=www.lysator.liu.se}}</ref>

BCPL handles bindings spanning separate [[compilation unit]]s in a unique way. There are no user-declarable global variables; instead, there is a global vector, similar to "blank common" in [[Fortran]].  All data shared between different compilation units comprises scalars and pointers to vectors stored in a pre-arranged place in the global vector.  Thus, the header files (files included during compilation using the "GET" directive) become the primary means of synchronizing global data between compilation units, containing "GLOBAL" directives that present lists of symbolic names, each paired with a number that associates the name with the corresponding numerically addressed word in the global vector.  As well as variables, the global vector contains bindings for external procedures.  This makes dynamic loading of compilation units very simple to achieve.  Instead of relying on the link loader of the underlying implementation, effectively, BCPL gives the programmer control of the linking process.{{Citation needed|date=January 2017}}

The global vector also made it very simple to replace or augment standard library routines. A program could save the pointer from the global vector to the original routine and replace it with a pointer to an alternative version. The alternative might call the original as part of its processing. This could be used as a quick ''ad hoc'' debugging aid.{{Citation needed|date=January 2017}}

BCPL was the first [[brace programming language]] and the braces survived the syntactical changes and have become a common means of denoting program source code statements. In practice, on limited keyboards of the day, source programs often used the sequences <code>$(</code> and <code>$)</code> or <code>[</code> and <code>]</code> in place of the symbols <code>{</code> and <code>}</code>. The single-line <code>//</code> [[comment (computer programming)|comment]]s of BCPL, which were not adopted by [[C (programming language)|C]], reappeared in [[C++]] and later in [[C99]].

The book ''BCPL: The language and its compiler'' describes the philosophy of BCPL as follows:
{{Blockquote|The philosophy of BCPL is not one of the tyrant who thinks he knows best and lays down the law on what is and what is not allowed; rather, BCPL acts more as a servant offering his services to the best of his ability without complaint, even when confronted with apparent nonsense.  The programmer is always assumed to know what he is doing and is not hemmed in by petty restrictions.<ref>{{Cite book|title=BCPL: The Language and its Compiler|last1=Richards|first1=Martin|last2=Whitby-Strevens|first2=Colin|publisher=Cambridge University Press|year=1980|isbn=978-0521785433|pages=5}}</ref>}}