Flow Control in INTERCAL via PLEASE ABSTAIN AI-pedia

The Compiler Language With No Pronounceable Acronym (INTERCAL) is an esoteric programming language designed in 1972 by Donald R. Woods and James M. Lyon, who were then students at Princeton University. INTERCAL was created as a parody of the dominant programming languages of the late 1960s and early 1970s, specifically targeting languages such as FORTRAN, ALGOL 60, COBOL, and PL/I. The core design principle of INTERCAL was to eliminate any feature, syntax, or construct that bore a resemblance to established programming practices. As a consequence of this principle, the designers rejected the most fundamental control flow mechanisms used in computing, including conditional branching statements such as IF-THEN-ELSE, loop constructs such as WHILE and FOR, and direct jump statements such as GOTO.

To enable arbitrary execution logic and maintain theoretical Turing completeness—the capability to simulate any single-taped Turing machine given sufficient memory—Woods and Lyon devised a control flow mechanism based on instruction suppression. Instead of testing a condition and jumping to a target memory location, an INTERCAL program modifies its own execution environment by dynamically disabling statements through the ABSTAIN FROM command. Disabled statements are skipped during execution, allowing subsequent instructions to execute in sequence. Statements can later be re-enabled using the complementary REINSTATE command.

The modifier PLEASE is frequently attached to ABSTAIN, producing the canonical command PLEASE ABSTAIN FROM. This occurs because INTERCAL enforces a compiler check known as the "politeness checker." The runtime system rejects programs that contain too few or too many polite prefixes. Flow control in INTERCAL is therefore characterized by a combination of instruction masking, subroutine stack manipulation, and lexical politeness balancing. This architecture forms one of the earliest and most complex examples of dynamic code modification used as a primary control flow model in computer science.

Historical Context and Design Philosophy

In the late 1960s and early 1970s, computer science was undergoing a transition toward structured programming. Edsger W. Dijkstra published his influential letter "Go To Statement Considered Harmful" in the Communications of the ACM in 1968, sparking industry-wide debate over control structures, block nesting, and software verification. At the same time, major programming languages introduced large sets of complex keywords, control flow variations, and intricate grammar rules. Languages like PL/I attempted to merge features from business and scientific computing, resulting in large, unwieldy specifications.

Donald R. Woods and James M. Lyon developed INTERCAL over the course of several days at Princeton University, publishing the original INTERCAL Programming Language Reference Manual on May 26, 1972. Their design philosophy was rooted in intentional subversion. If a particular programming convention was considered standard, convenient, or readable in contemporary languages, INTERCAL required the opposite approach. The language deliberately lacked standard arithmetic operators, using instead bitwise operations such as "mingle" (represented by a large cent sign ¢ or a double quote ") and "select" (represented by a slash / or a tilde ~).

The total exclusion of standard control flow created a significant design challenge: how could a programmer execute conditional logic if the language prohibited conditional comparisons? Woods and Lyon rejected IF, CASE, SWITCH, and all forms of relational operators (such as equal to, greater than, or less than). They also rejected conventional labels and unconditional jumps. Their solution was to make the source code mutable at runtime, not by rewriting bytes in memory, but by granting the runtime the ability to toggle the operational status of lines and categories of statements.

The Base Execution Model

To understand how ABSTAIN functions as a flow control mechanism, one must first examine how INTERCAL processes instructions in the absence of abstention.

Linear Execution and Statement Numbering

An INTERCAL program consists of a sequence of lines. Each line can optionally begin with a statement label enclosed in parentheses, such as (10) or (100). Unlike early versions of BASIC or FORTRAN, where line numbers determined the sequence of execution, INTERCAL statement labels have no bearing on execution order. Statements are executed sequentially in physical source code order, from top to bottom, regardless of what numeric values appear inside the parentheses. Statement labels serve exclusively as targets for other statements to reference.

Each executable statement must begin with a qualifier that sets the instruction's validity under the compiler's politeness rules. The valid qualifiers are:

• DO
• PLEASE
• PLEASE DO (or DO PLEASE)

These prefixes have identical functional meaning regarding execution; their distinction exists entirely to satisfy the language's politeness checker.

Branching via NEXT, RESUME, and FORGET

Because INTERCAL lacks a GOTO statement, transfer of control across non-adjacent lines of code is handled by the NEXT statement. The syntax is:

DO (label) NEXT

The NEXT command acts as an unconditional subroutine call. When executed, the runtime pushes the address of the immediately following statement onto an internal return address stack, known as the NEXT stack. Control then transfers unconditionally to the statement bearing the specified label.

Returning from a NEXT call is accomplished using the RESUME statement:

DO RESUME expression

The RESUME command evaluates an expression, which must evaluate to a positive integer n. It then pops n entries off the NEXT stack and transfers control to the address stored at that nth popped location. If n is 1, the program returns to the instruction immediately following the most recent NEXT statement. If n is greater than 1, the program returns through multiple levels of subroutine calls simultaneously, effectively skipping intervening return points.

A related command, FORGET, evaluates an expression to an integer n and pops n entries off the NEXT stack without transferring control. Execution simply falls through to the next physical line. The original INTERCAL-72 implementation hardcoded the size of the NEXT stack to 78 or 80 levels. Exceeding this stack depth caused the compiler to crash with an unrecoverable runtime error: ICL123 PROGRAM HAS DISAPPEARED INTO THE BLACK LAGOON.

While NEXT and RESUME provide a mechanism for subroutines, they do not provide conditional branching on their own. They transfer control unconditionally. Constructing a conditional branch requires pairing these stack operations with statement suppression.

The Syntax and Semantics of ABSTAIN and REINSTATE

The ABSTAIN command instructs the runtime system to deactivate one or more statements. When a statement is deactivated, it remains part of the program structure, and its statement label remains valid, but its operational logic is bypassed when the execution pointer encounters it.

Label-Based Abstention

The most direct form of abstention targets a specific statement label:

PLEASE ABSTAIN FROM (10)

When this statement executes, the runtime updates its internal dispatch table to mark line (10) as abstained. If execution subsequently reaches line (10), the statement acts as a no-op (no-operation). The program does nothing on that line and immediately advances to the next physical line in the file.

The counterpart to ABSTAIN is REINSTATE:

PLEASE REINSTATE (10)

Executing this command clears the abstention flag for line (10). If execution reaches line (10) after reinstatement, the statement executes its original logic normally.

Gerund-Based Abstention

INTERCAL permits abstention from entire classes of statements simultaneously. In grammar, a gerund is the noun form of a verb ending in "-ing". INTERCAL uses gerund keywords to represent every major statement type in the language specification. The command takes the following form:

PLEASE ABSTAIN FROM gerund

When a gerund abstention is invoked, every statement in the program that belongs to that syntactic category is immediately disabled, regardless of its location in the source code. The ten standard statement gerunds in INTERCAL are detailed below:

Gerund	Target Statement Type	Functional Impact When Abstained
CALCULATING	Variable assignments (<-)	Suppresses all variable updates and expression evaluations.
NEXTING	Subroutine jumps (NEXT)	Prevents subroutine calls; jump statements are treated as no-ops.
RESUMING	Stack returns (RESUME)	Prevents subroutine returns; execution cannot pop return frames.
FORGETTING	Stack discards (FORGET)	Prevents removal of return stack frames without jumping.
IGNORING	Variable locking (IGNORE)	Suppresses the command that prevents variables from changing.
REMEMBERING	Variable unlocking (REMEMBER)	Suppresses the restoration of variable mutation capabilities.
ABSTAINING	Suppression commands (ABSTAIN)	Disables the ability to abstain from any further statements.
REINSTATING	Restoration commands (REINSTATE)	Disables the ability to restore any previously abstained statements.
STASHING	Variable pushing (STASH)	Suppresses saving variable values onto the variable stack.
RETRIEVING	Variable popping (RETRIEVE)	Suppresses restoring variable values from the variable stack.

Gerund abstentions can also be reversed using REINSTATE:

PLEASE REINSTATE CALCULATING

Once reinstated, all assignment statements throughout the program resume normal execution when encountered by the program counter.

Meta-Abstention and Self-Modifying Edge Cases

Because ABSTAINING and REINSTATING are themselves valid gerunds, INTERCAL allows programmers to disable the mechanisms of control flow themselves:

PLEASE ABSTAIN FROM ABSTAINING

Executing this instruction disables all subsequent ABSTAIN statements across the entire program. Any line attempting to execute an ABSTAIN FROM instruction will be bypassed as a no-op until a REINSTATE ABSTAINING command is issued. If a program executes PLEASE ABSTAIN FROM REINSTATING, it loses the ability to restore any statements that have been deactivated, making all subsequent abstentions permanent for the duration of the runtime session.

Another common idiom is self-abstention. A statement can reference its own label:

(50) PLEASE ABSTAIN FROM (50)

When execution reaches line (50) for the first time, it executes, marking line (50) as abstained. If execution loops back to line (50) later in the program, the statement does not execute again. Self-abstention allows the construction of one-time initialization blocks, run-once gates, and latching switches.

The Politeness Checker

The modifier PLEASE is not an optional stylistic preference; it is enforced by a quantitative syntactic rule known as the politeness checker. Woods and Lyon introduced this mechanism to satirize what they viewed as arbitrary constraints and bureaucratic language specifications in commercial systems.

The compiler monitors the statistical distribution of statements that contain the keyword PLEASE. The politeness rules enforce both a lower bound and an upper bound:

• Under-politeness: If fewer than one-fifth (20%) of the statements in a program begin with PLEASE or PLEASE DO, the compiler rejects the program, issuing error code ICL079 PROGRAMMER IS INSUFFICIENTLY POLITE.
• Over-politeness: If more than one-third (approximately 33.3%) of the statements begin with PLEASE or PLEASE DO, the compiler rejects the program, issuing error code ICL099 PROGRAMMER IS OVERLY POLITE.

To produce an acceptable program, between 20% and 33.3% of the statements must contain PLEASE. Because control flow statements such as ABSTAIN and REINSTATE are central to program structure, developers traditionally use them to regulate this balance. Writing PLEASE ABSTAIN FROM (10) satisfies both the requirement for dynamic line suppression and the requirement for source politeness. A developer who inadvertently uses DO ABSTAIN FROM (10) throughout a program risks an ICL079 compilation failure, while overusing PLEASE leads to immediate failure under ICL099.

Mechanisms of Flow Control: How ABSTAIN Replaces IF

Without an IF keyword or conditional jump instructions, conditional branching must be synthesized. In modern computer architecture, conditional execution relies on evaluating a predicate (a boolean true or false expression) and branching to different instruction addresses based on the result. In INTERCAL, conditional execution is achieved by using computed state to alter the active set of instructions.

The Branch Gate Pattern

The most common method for implementing an IF-THEN-ELSE structure is the "branch gate" pattern. In this pattern, an unconditional jump is placed directly in the execution path, and the program decides whether to silence or enable that jump before reaching it.

Consider the following conceptual design:

1. The programmer writes an unconditional jump at statement (20): DO (100) NEXT.
2. If the condition is true, the program leaves line (20) active. When the execution path reaches line (20), control jumps to line (100) (the THEN block).
3. If the condition is false, the program executes PLEASE ABSTAIN FROM (20). When execution reaches line (20), the jump is ignored, and execution falls through to line (21) (the ELSE block).

The critical challenge in this paradigm is determining how to execute PLEASE ABSTAIN FROM (20) conditionally in the first place. Because the program cannot execute a statement conditionally based on an inline test, it must use the calculated value of an expression to determine which code block to enter.

The Computed RESUME Dispatcher

To bridge the gap between numerical evaluation and statement abstention, INTERCAL programmers combine the RESUME statement with subroutine calls. In INTERCAL, arithmetic operations on 16-bit or 32-bit integers yield numeric results. Through complex bitwise manipulation (using the select ~ and mingle ¢ operators), a logical condition can be normalized so that it results in either the number 1 or the number 2.

A normalized condition is then passed to a dispatcher structure:

(1) DO (1000) NEXT
(2) DO (20) NEXT
(3) DO (30) NEXT

Inside the subroutine at (1000), the program calculates the conditional expression, storing either 1 or 2 in a 16-bit variable, such as .1. The subroutine then executes:

DO RESUME .1

The behavior of the program now diverges depending on the value of .1:

• If .1 equals 1, RESUME pops 1 level off the NEXT stack. Control returns to line (2), which immediately jumps to line (20). Line (20) contains code that executes PLEASE ABSTAIN FROM (gate).
• If .1 equals 2, RESUME pops 2 levels off the NEXT stack. It bypasses the return address for line (1) entirely and returns to whatever statement called the current routine, or skips ahead to an alternate return target.

Once the program reaches an isolated target block, it executes the necessary ABSTAIN or REINSTATE statements, configuring the execution mask for subsequent iterations. Control then transfers back to the main processing path, where the modified branch gates enforce the calculated path.

Loop Construction

Loops in standard languages repeat execution while a condition remains true. In INTERCAL, a loop is constructed by establishing a backwards jump via NEXT and conditionally suppressing that jump when termination criteria are met.

A loop structure typically follows this sequence:

(10) DO (100) NEXT
(11) DO (200) NEXT
(12) DO (13) NEXT
(13) PLEASE ABSTAIN FROM (14)
(14) DO (10) NEXT
(15) PLEASE REINSTATE (14)

In this architecture:

1. Line (10) performs the body of the loop.
2. Line (11) evaluates loop termination criteria. If the loop should end, line (11) calls a routine that executes PLEASE REINSTATE (14) or manipulates the gate.
3. Line (14) is the jump back to the beginning of the loop (line (10)).
4. If line (14) has been abstained from, execution falls through line (14) to line (15), which terminates the loop or cleans up state before continuing.

Without structured blocks, loops require precise management of the NEXT stack. Because every execution of NEXT consumes a slot on the return stack, an unbounded loop that uses NEXT to jump backwards will inevitably crash when the stack reaches its 80-frame capacity. To prevent this, the programmer must execute DO FORGET #1 inside each loop cycle. The FORGET command pops the unused return address off the stack, preventing stack overflow while allowing the loop to repeat indefinitely.

Concrete Code Walkthrough

To observe how PLEASE ABSTAIN operates during execution, consider the following INTERCAL routine. The objective of this routine is to set variable .2 to 1 if variable .1 equals 0, and set .2 to 2 if .1 is non-zero. This simulates a standard IF-THEN-ELSE branching construct.

(1)   PLEASE DO .2 <- #0
(2)   DO (10) NEXT
(3)   DO (20) NEXT
(4)   DO (30) NEXT

      ( Branch Gate 1: If active, sets .2 to 1 )
(10)  PLEASE DO .2 <- #1
(11)  DO (40) NEXT

      ( Branch Gate 2: If active, sets .2 to 2 )
(20)  PLEASE DO .2 <- #2
(21)  DO (40) NEXT

      ( Deciding routine )
(30)  PLEASE ABSTAIN FROM (10)
(31)  PLEASE ABSTAIN FROM (20)
(32)  ( Logic to analyze .1 is executed here )
      ( If .1 is zero, reinstate line 10 )
(33)  DO REINSTATE (10)
      ( Return to caller )
(34)  DO RESUME #1

      ( Exit routine )
(40)  DO FORGET #1
(41)  PLEASE REINSTATE (10)
(42)  PLEASE REINSTATE (20)

The program follows these discrete mechanical steps:

1. Line 1: Initializes variable .2 to 0 using the assignment operator <-. The PLEASE DO prefix contributes to the politeness balance.
2. Lines 2–4: The main sequence begins. Execution branches into line (10), then line (20), then line (30) sequentially, unless statements are suppressed.
3. Initial Pass / Configuration: In a complete implementation, line (30) through (34) is executed first via an initial setup jump. Lines (30) and (31) explicitly disable both branch options: lines (10) and (20). This ensures that no branches fire prematurely.
4. State Evaluation: The logic at line (32) calculates whether .1 is 0. If the condition is met, line (33) executes DO REINSTATE (10). This selectively turns line (10) back on while leaving line (20) disabled.
5. Execution of Branch: Control resumes back at the dispatch sequence. When the execution pointer encounters line (10), the statement is active, so .2 <- #1 executes. Line (11) then jumps control immediately to the exit routine at line (40).
6. Bypassing Inactive Branches: If the condition had instead reinstated line (20), the execution pointer reaching line (10) would find it abstained. The runtime would skip line (10) and line (11) entirely, falling directly into line (20), where .2 <- #2 would execute.
7. Cleanup: The exit routine at line (40) uses DO FORGET #1 to purge the return stack entry created by NEXT, preventing stack buildup. Lines (41) and (42) reset the environment by reinstating all gates for subsequent operations.

Dialect Implementations and Compiler Architecture

The semantics of ABSTAIN have evolved across several major dialects of INTERCAL, shifting from early batch mainframe environments to modern virtual machines and C-transpilers.

INTERCAL-72

The original implementation was written by Woods and Lyon in 1972 for the IBM System/360 architecture, operating under OS/360. It was implemented using an interpreter written in SPITBOL (a fast implementation of SNOBOL4). In INTERCAL-72, the program text was represented as an in-memory array of structures.

Each entry in the statement table contained:

• The numeric statement label (or zero if unlabeled).
• The internal statement type identifier (mapping to the ten gerunds).
• A pointer to the tokenized parse tree for the line.
• An abstention status bit: 0 indicating enabled, 1 indicating abstained.

In addition to per-statement status bits, the runtime maintained a global 10-bit bitmask representing the ten gerund categories. When evaluating whether to execute a statement, the interpreter performed a logical check: if either the statement's individual abstention bit was set or the bit corresponding to its gerund was set in the global mask, the execution of the statement was skipped, and the interpreter advanced its internal index.

C-INTERCAL

In 1990, Eric S. Raymond and Alex Smith created C-INTERCAL, a portable implementation written in C that modernized the language and made it widely accessible on Unix-like operating systems. C-INTERCAL remains the reference implementation for standard INTERCAL programming. Rather than interpreting source lines directly, C-INTERCAL compiles INTERCAL code into native C source code, which is then compiled by a standard C compiler (such as GCC).

To implement ABSTAIN and REINSTATE within compiled C code, the C-INTERCAL compiler (ick) generates an abstention tracking table. Each statement in the original INTERCAL program is assigned an integer index from 0 to N-1. The generated C code includes an array of character flags:

unsigned char item_abstained[TOTAL_STATEMENTS];
unsigned long gerund_abstained;

Before executing the C code generated for an INTERCAL statement, the runtime checks these flags:

if (!item_abstained[statement_index] && !(gerund_abstained & STATEMENT_GERUND_BIT)) {
    /* Generated code for the INTERCAL statement */
}

When an ABSTAIN FROM (label) statement executes, the compiled C code locates the index corresponding to that label and sets item_abstained[target_index] = 1. When an ABSTAIN FROM gerund executes, the bitwise flag for that gerund is toggled on via gerund_abstained |= GERUND_BIT. C-INTERCAL also supports "double abstention" tracking in certain operational modes, where abstentions can be stacked, requiring an equivalent number of REINSTATE calls to reactivate the line.

C-INTERCAL also introduced several extensions, including the READ OUT statement for input/output using Roman numerals, and support for running on modern 32-bit and 64-bit POSIX architectures.

CLC-INTERCAL

CLC-INTERCAL was developed by Claudio Calvelli starting in the late 1990s. It represents a clean-room redesign of the language implemented in Perl. Calvelli formalized INTERCAL's grammar, creating a compiler that allows runtime modification of the language grammar itself.

In CLC-INTERCAL, the abstention system was generalized significantly:

• Range Abstention: Statements can be disabled across syntactic ranges, allowing a program to abstain from blocks of lines defined by boundary labels.
• Class Abstention: Users can abstain from user-defined syntactic classes and compiler extensions, such as multithreading operations or networking sockets.
• Quantum INTERCAL: CLC-INTERCAL introduced quantum computing extensions, where statements can exist in superpositions of being simultaneously abstained and reinstated until observed by an I/O operation.

INTERCAL64

INTERCAL64 was created by Jason Whittington to adapt INTERCAL to native 64-bit systems, providing support for 64-bit integers (quadwords) and modern memory-addressing limits. The maintenance of INTERCAL64 and its dialect variants has since been managed by an esoteric computing group named "PLEASE ABSTAIN", named in honor of the control flow mechanism.

Theoretical and Practical Implications

While designed as a parody, the control structure created by PLEASE ABSTAIN provides insights into computing theory, program comprehension, and language design.

Turing Completeness and the Turing Tarpit

In theoretical computer science, a programming language is Turing-complete if it can compute any partial function that can be computed by a Turing machine. To achieve Turing completeness, a language must have:

1. A mechanism for conditional branching (the ability to choose an execution path based on data).
2. A mechanism for unbounded state or arbitrary iteration (the ability to loop or recurse indefinitely).
3. Sufficient memory representation (the ability to read and write an arbitrary amount of data).

INTERCAL fulfills condition (1) through the combination of ABSTAIN, REINSTATE, and RESUME. It fulfills condition (2) through NEXT combined with FORGET. It fulfills condition (3) through its 16-bit and 32-bit variables and multidimensional arrays. Consequently, despite having no conventional flow control keywords, INTERCAL is fully Turing-complete.

This places INTERCAL into the category often referred to by computer scientists as a "Turing tarpit"—a term coined by Alan Perlis in his 1982 paper Epigrams on Programming: "Beware of the Turing tarpit in which everything is possible but nothing of interest is easy." In a Turing tarpit, basic computational primitives are available, but accomplishing simple tasks requires enormous structural overhead.

Comparison to Self-Modifying Machine Code

In early computer engineering, particularly during the era of first-generation computers (such as the EDSAC or IBM 704) and early 8-bit microprocessors, memory was severely restricted. Programmers frequently used self-modifying code to save bytes. A programmer would write a program that directly overwrote instruction opcodes in memory, changing an unconditional jump into a no-op instruction (NOP, hexadecimal 0x90 on x86 architectures) to permit fall-through, or overwriting an immediate memory address inside an instruction.

PLEASE ABSTAIN implements a higher-level, managed abstraction of self-modifying code. The physical text of the program in memory does not change: instructions are not overwritten with random bytes, and parse trees are not invalidated. Instead, the runtime environment maintains an execution mask that alters the program's response to its own instruction sequence. This creates the debugging difficulties of self-modifying machine code while remaining strictly within the confines of a high-level language runtime.

Action at a Distance and Cognitive Load

In software engineering, "action at a distance" is an antipattern in which a component of a program modifies the behavior of another distant component without an explicit, visible connection between them. Global variables with unrestricted write access are a standard example of action at a distance.

PLEASE ABSTAIN represents an extreme form of action at a distance. In a structured language such as C, Java, or Python, reading a routine allows the programmer to deduce its execution path based on local syntax: an if statement checks its condition, executes its nested block, and returns. In INTERCAL, local analysis of code is impossible. A statement on line (500) can execute:

PLEASE ABSTAIN FROM (10)

A programmer inspecting line (10) cannot know whether the statement will execute simply by reading lines (1) through (9). Line (10) can be silenced or reinstated by statements located anywhere in the codebase, executed at any prior point in runtime history. Furthermore, executing PLEASE ABSTAIN FROM CALCULATING globally halts all arithmetic operations across all subroutines, instantly invalidating the functional assumptions of unrelated modules.

For individuals analyzing software structure, including autistic programmers who value deterministic, rule-based systems and explicit logic, INTERCAL's model represents an inversion of predictability. In standard procedural languages, rules are local and explicit; the lexical structure reflects the temporal execution path. In INTERCAL, the temporal execution path is continually divorced from the lexical layout through non-local state modifications. Tracing an INTERCAL program requires maintaining two distinct mental models simultaneously: the static sequence of physical lines, and the dynamically shifting bitmask of activated and deactivated statements.

Summary of Related Error Conditions

Because flow control via ABSTAIN intersects with politeness checks and call stack management, common runtime failures produce specific INTERCAL error messages. The table below lists error codes associated with control flow operations in standard C-INTERCAL:

Error Code	Canonical Error Message	Underlying Cause
ICL079	PROGRAMMER IS INSUFFICIENTLY POLITE	Less than 20% of statements contain the PLEASE qualifier.
ICL099	PROGRAMMER IS OVERLY POLITE	More than 33.3% of statements contain the PLEASE qualifier.
ICL017	CANNOT ABSTAIN FROM UNLABELED STATEMENT	Attempting to run ABSTAIN FROM (label) where the label does not exist.
ICL063	NOT A VALID GERUND	Syntax error following ABSTAIN FROM; keyword does not match a known statement type.
ICL123	PROGRAM HAS DISAPPEARED INTO THE BLACK LAGOON	The NEXT stack exceeded its hard limit (typically 80 calls) without being cleared by FORGET or RESUME.
ICL256	TRANSLATION CEASED DUE TO EXCESSIVE COMPLEXITY	General compiler failure when nested self-modifications create ambiguous parse states.

These error codes are deliberately phrased in humorous language, but they correspond to concrete execution faults within the runtime system. The ICL123 error, in particular, represents a stack overflow condition caused by improper management of loops that rely on NEXT and ABSTAIN.

See also

• Esoteric programming language
• C-INTERCAL
• Donald R. Woods
• Eric S. Raymond
• Self-modifying code
• Structured programming
• Turing tarpit
• Call stack
• Spaghetti code