20. Glossary
This page collects the technical terminology used throughout the Gazprea specification. Its purpose is threefold: to fix the meaning of the words we use so that the specification is self-consistent, to point the reader at the authoritative literature behind each term, and to give students a jumping-off point when they need to specify a language or compiler task of their own.
Every entry below has a primary citation to an authoritative source: an ISO/IEC or IEEE standard, the documentation of an ongoing industrial open-source project (LLVM, GCC, GNU Binutils), or a peer-reviewed publication in a respected venue. Where a term has a widely-used effective reference (e.g. cppreference for the C++ value categories), that reference appears alongside the authoritative citation and is explicitly labelled as non-normative.
Every glossary entry is a Sphinx :term: target and can be
cross-referenced from anywhere in the specification. For example, a
sentence in another chapter can read
“the value must be a constant expression“.
Note
The entries here are definitions of terminology, not statements of
Gazprea semantics. Where Gazprea re-uses a word from another
language (for instance type qualifier, which C reserves for
const/volatile/restrict/_Atomic but Gazprea uses for
the mutability distinction const/var), the glossary explains
the source of the word and points to the Gazprea chapter that gives
its language-specific meaning.
20.1. Terms
- aggregate type
A type composed of subordinate members of possibly-different types. In ISO C the term denotes array and structure types collectively [2]. In Gazprea the aggregate types are arrays, vectors, tuples, strings, and structs; see Types.
Terminology note. Ada calls this umbrella category composite type rather than aggregate type [1]. ISO C also defines composite type but with an unrelated meaning – it is the merged type produced from two compatible declarations of the same entity, not a category of types [2]. Because “composite” is a false friend between the two standards, Gazprea follows the C/C++ convention and uses aggregate type as the umbrella term.
- assembler
A program that translates assembly language into relocatable machine code [14]. In the LLVM toolchain the assembler role is played by the MC layer and the
llvm-mcdriver [9].- compile time
The interval during which the source program is being translated by the compiler, before program execution begins. Ada states the contrast explicitly: “At compile time, the declaration of an entity declares the entity. At run time, the elaboration of the declaration creates the entity” [1]. The C standard specifies the phases of translation in ISO/IEC 9899 §5.1.1.2 [2].
- compiler
A program that reads a source program in one language and produces an equivalent program in a target language [14]. GCC and LLVM/Clang are two production compilers whose internal architectures follow the classical front-end / middle-end / back-end division [6] [7].
Compiler subtypes. The unmarked base case – a compiler whose target is machine code executable by a CPU – has no distinct term of art; it is simply compiler. Two marked variants are recognised:
A source-to-source translator compiles from one high-level language to another high-level language [14]. The informal term transpiler is sometimes used for the same concept; it is not defined in any ISO/IEC standard, LLVM document, or GCC document, and the first attempt at a peer-reviewed generic definition appears in a 2023 mapping review [19]. Prefer source-to-source translator in the formal register.
A cross-compiler runs on one host platform and emits code for a different target platform (CPU or operating system) [10] [11]. Cross-compilation is orthogonal to whether the target language is machine code or another high-level language.
- constant expression
An expression that a conforming implementation is required to be able to evaluate during translation. In C++, “expressions that satisfy these requirements … are called constant expressions” [3]. See Constant Expressions for Gazprea’s specific rules; note that in Gazprea the noun is often abbreviated
constexpr, which is not a keyword.- cross-compiler
A compiler that runs on one host platform (CPU + operating system) and produces code for a different target platform. Clang is designed as a native cross-compiler in which one binary can target every supported architecture via a
-targetflag [10]; GCC by contrast requires a separately-built host/target binary pair [11].- declaration
A construct that specifies the interpretation and attributes of a set of identifiers [2]. A declaration in Gazprea has the form defined in Declarations.
- definition
A declaration that additionally causes storage to be reserved for an object, or that supplies the body of a function or procedure [2]. The C++ grammar production and definitional requirements are given in [basic.def] [3]; Gazprea does not adopt C++’s one-definition rule, so the citation is informational only.
- domain
In a Gazprea iterator loop or domain expression, the array-typed operand to the right of
in. The domain is evaluated exactly once, when control first reaches the loop; the resulting value is captured for the lifetime of the loop, and subsequent modifications to any variable that appeared in the domain expression do not affect it. In general PL usage the analogous notion is the range of a range-based loop (C++for (x : R)[3]) or the iteration scheme of an Adaforloop [1].- domain expression
The whole Gazprea construct
x in Eused inside an iterator loop or generator: the iterator variablexbound over the domainE. Domain expressions can only appear inside iterator loops and generators.- dynamic
Determined or known at run time. Used as the antonym of static. ISO/IEC 9899 §6.2.4 uses “dynamic” implicitly by contrasting static storage duration with automatic and allocated storage durations whose extents are established during execution [2].
- expression
“A sequence of operators and operands that specifies a computation. An expression can result in a value and can cause side effects” [3]. The syntactic shape of expressions in Gazprea is defined in Expressions.
- functional purity
An informal property of a language, expression, or function: the absence of observable side effects. There is no ISO definition; the standard academic reference is Strachey’s characterisation of referential transparency [20]. Gazprea invokes functional purity as the motivation for forbidding mutable globals and for the input-only nature of function arguments.
- glvalue
A “generalized” lvalue: “an expression whose evaluation determines the identity of an object, function, non-static data member, or a direct base class relationship” [3]. One of the three C++11 value categories (together with prvalue and xvalue). See the non-normative summary at [23] for an accessible introduction.
- identifier
“A sequence of nondigit characters … and digits, which designates one or more entities” [2]. Gazprea’s lexical rules for identifiers are in Identifiers.
- ill-formed
A program is ill-formed if it is not well-formed [4]. A conforming implementation is required to issue a diagnostic for at least one violation of a diagnosable rule in an ill-formed program.
- implementation-defined behavior
“Unspecified behavior where each implementation documents how the choice is made” [2]. Distinct from unspecified behavior (no documentation obligation) and undefined behavior (no requirements at all).
Gazprea policy. A conforming Gazprea implementation must not have any user-distinguishable implementation-defined behavior, unspecified behavior, or undefined behavior: every program is either well-formed and produces the output required by this specification, or it is ill-formed and the implementation emits an error. The reason these C/C++ terms appear in this glossary is definitional – the Gazprea prose uses them to say what the language does not allow, not to reserve latitude for implementers.
- implicit conversion
An automatic conversion inserted by the language, without a cast, to make an operand’s type match a required target type. ISO C collects the rules under §6.3 “Conversions” [2].
Gazprea uses this general term only in the glossary. In the Gazprea specification proper the analogous mechanism is called type promotion, and it is deliberately distinct from type casting: type promotion is the implicit mechanism (e.g.
integer->realwhen arithmetic mixes them), while type casting is the explicit mechanism invoked viaas<toType>(value). The two are not interchangeable in Gazprea: some casts have no corresponding implicit promotion.- initializer
The syntactic element that supplies an initial value to a newly declared object. In C++ the grammar is given in
[dcl.init.general][3]. Gazprea’s initializer positions and rules are covered in Declarations.- interpreter
A program that does not produce a target program, but “appears to directly execute the operations specified in the source program on inputs supplied by the user” [14]. Contrast with compiler and translator.
- iterator
A cursor that yields the elements of a collection one at a time, in a defined order. The concept is standard across modern language families: Python defines it operationally through the iterator protocol (
__iter__/__next__) [18]; C++ defines iterators as generalised pointers into a range, with the requirements collected in [iterator.requirements] [3]. In Gazprea the word is used informally for the mechanism that a iterator loop uses to walk its domain; the visible binding is the iterator variable.- iterator variable
In a Gazprea iterator loop or domain expression, the identifier to the left of
in. A fresh binding is introduced at the start of every iteration (see re-initialization) and destroyed at the end of that iteration. In other languages the equivalent binding is Ada’s loop parameter [1] and C++’s for-range-declaration [3].- lifetime
“The portion of program execution during which storage is guaranteed to be reserved” for an object. “An object exists, has a constant address, and retains its last-stored value throughout its lifetime” [2].
Rust makes lifetime a first-class object of the type system – every reference carries a compile-time lifetime parameter that the borrow-checker uses to prove memory safety without a garbage collector. The Rust Reference chapter on lifetimes [12] and the Rustonomicon chapter on references [13] together give the most operationally-precise treatment of the concept in a production language; students designing safe systems languages typically start there.
- link time
The interval during which the linker runs, after translation of each translation unit and before program execution. ISO C describes this as translation phase 8 [2]. Link-time optimisation (LTO), performed at this point, is documented for the LLVM toolchain in [8].
- linker
A program that combines separately-translated translation units into a single executable, resolving external references between them. The GNU
lddocumentation gives the canonical operational description [5]. See also link time.- literal
A token whose value is the token itself: integer, floating-point, character, string, boolean, and (in C++) pointer literals [3]. Contrast a literal with a constant expression, which may be composed of literals and other operators.
- lvalue
“An expression (with an object type other than void) that potentially designates an object” [2]. C++ defines an lvalue as “a glvalue that is not an xvalue” [3]. The historical origin of the “l-value” and “r-value” terminology is Strachey’s 1967 lectures, published as [20]. See the non-normative summary [23] for a modern taxonomy.
- name binding
The association of an identifier with an entity (an object, function, type, etc.) within a scope. ISO C uses the operational phrase “the declaration … is visible at the point the identifier occurs” [2] rather than the term “binding”. The academic origin of “binding” as the association of names with denotable values in an environment is Strachey [20].
- object
“A region of data storage in the execution environment, the contents of which can represent values” [2]. In this glossary the word always refers to the run-time storage-region entity, in the ISO C sense.
Gazprea note. Gazprea is not an object-oriented language – it has no user-defined classes, no inheritance, and no virtual dispatch. The one place the Gazprea prose reaches for OO-flavoured wording is the aggregate vector type, which exposes methods (
push,len,append) via dot syntax. Those are built-in operations on the vector’s storage-region object, not a user-facing object-model feature; when a Gazprea sentence says “object” it always means the storage region, never a vector-as-instance-of-a-class.- primitive type
A type provided directly by the language and not composed of other types. The LLVM Language Reference distinguishes primitive types (
i32, floating-point types,void, etc.) from derived and aggregate types [7]. In Gazprea the primitive types areboolean,integer,real, andcharacter.- prvalue
A “pure r-value”: “an expression whose evaluation initializes an object or computes the value of an operand of an operator … or an expression that has type cv void” [3]. One of the three C++11 value categories. See the non-normative summary at [23] for an accessible introduction.
- pure function
See functional purity.
- re-declaration
A second (or nth) declaration of the same identifier within a given scope. In Gazprea a re-declaration always introduces a fresh binding that shadows the enclosing binding for the remainder of the scope; it does not modify the original. The general PL concept is scope shadowing [16].
Re-declarations arise in every scope, not only iterator loops. The specific case where a re-declaration inside an iterator loop body shadows the iterator variable is called out under re-initialization: the shadow lives for one iteration only, and the next iteration re-initializes the iterator variable normally.
- re-initialization
In a Gazprea iterator loop, the binding, performed at the start of every iteration, of the iterator variable to the next element of the captured domain. Because re-initialization introduces a fresh binding from the captured domain, neither reassignment of the loop domain expression nor mutation of the iterator variable inside the body carries information into the next iteration.
- referential transparency
The property that an expression’s value depends only on the values of its subexpressions, so that any subexpression may be replaced by an equal-valued subexpression without changing the whole [20]. The term is due to Quine [17].
Gazprea guarantees referential transparency only for pure functions (see Functions) and for expressions built exclusively out of them. It is not guaranteed for procedures, which may have side effects and whose return value can therefore change between calls with the same arguments; nor for any expression that transitively depends on a procedure call. This is why Gazprea forbids calling procedures inside functions, forbids mutable globals, and restricts the operators that may combine a procedure call’s return value (see Procedures).
- run time
The interval during which the program is executing, after translation and link time are complete. Ada defines the corresponding process, execution, as “the process by which a construct achieves its run-time effect” [1].
- rvalue
C++ defines an rvalue as “a prvalue or an xvalue” [3]. In C the term is used informally as the complement of lvalue. Historical origin: Strachey [20]. See the non-normative summary at [23] for the modern C++ taxonomy.
- scalar type
A type whose values are atomic in the sense that they are not composed of sub-elements. ISO C: “Arithmetic types and pointer types are collectively called scalar types” [2]. Ada groups enumeration, integer, and real types as scalar [1]. In Gazprea the scalar types are
boolean,integer,real, andcharacter.- scope
“The region of program text within which [an] identifier is visible” [2]. ISO C distinguishes four kinds of scope: function, file, block, and function prototype. Gazprea’s scope rules are described in Declarations and Namespaces.
- sequenced before
“An asymmetric, transitive, pair-wise relation between evaluations executed by a single thread … if A is sequenced before B (or, equivalently, B is sequenced after A), then the execution of A shall precede the execution of B” [3]. The relation supplants the older ISO C sequence point model for describing the ordering of side effects.
- side effect
“Reading an object designated by a volatile glvalue, modifying an object, … calling a library I/O function, or calling a function that does any of those operations” – any “change in the state of the execution or translation environment” [3]. ISO C gives an equivalent enumeration [2].
- source-to-source translator
A compiler that translates from one high-level language into another high-level language rather than into machine code [14]. The informal industry term transpiler denotes the same concept; see the note in compiler.
- statement
A syntactic construct whose primary role is to be executed for its effect rather than to compute a value. The C++ grammar enumerates the kinds of statement in
[stmt.pre][3]. Gazprea’s statements are covered in Statements.- static
Determined or known at compile time. Ada gives the cleanest formal definition: “Static means determinable at compile time, using the declared properties or values of the program entities” [1]. Contrast with dynamic.
- storage duration
The property of an object that determines its lifetime. ISO C defines four storage durations: static, thread, automatic, and allocated [2].
- translation
The act of processing a source program to produce a target program. ISO C notes that “translation units may be separately translated and then later linked to produce an executable program” [2]. Distinct from compile time, which refers to when translation happens.
- translation unit
“The unit of program text after preprocessing … consist[ing] of a sequence of external declarations” [2]. In Gazprea each
.gazsource file corresponds to one translation unit.- translator
A generic term for a program that reads a source program and writes an equivalent program in a different language; a compiler, assembler, and source-to-source converter are all translators [14].
- type
A characterisation of a set of values together with a set of operations on those values [1] [16]. Gazprea’s types are enumerated in Types.
- type casting
Explicit conversion of a value from one type to another, invoked by an explicit syntactic form. ISO C’s cast operator is defined in §6.5.4 [2]. Gazprea’s casting rules are covered in Type Casting.
- type inference
The compile-time reconstruction of a type that has been omitted from a program. Milner’s polymorphic type inference (algorithm W), and the accompanying soundness result, is the foundational academic reference [15]. Gazprea’s type inference is described in Type Inference.
- type promotion
In general PL usage, an implicit conversion in which an operand of one type is converted to a “wider” or “richer” type before an operation; ISO C specifies integer promotions (§6.3.1.1) and the usual arithmetic conversions (§6.3.1.8) [2].
In Gazprea, type promotion is the specific implicit-conversion mechanism defined in Type Promotion (integer to real, scalar to array, tuple to tuple, string to character-vector and back). It is deliberately separate from type casting, which is the explicit mechanism invoked via
as<toType>(value). Every promotion is available as an explicit cast, but not every cast is available as an implicit promotion.- type qualifier
In ISO C the term refers to the cv-qualifiers
const,restrict,volatile, and_Atomic, defined in §6.7.3 [2]. Gazprea re-uses the phrase for the mutability qualifiersconstandvar(see Type Qualifiers); this is a terminological convention, not an assertion that Gazprea’s qualifiers behave like C’s.- type system
A tractable syntactic method for classifying phrases of a language by the kinds of values they compute [16]. Type systems are traditionally divided into static systems (checking performed before execution) and dynamic systems (checking performed during execution); see Pierce, Chapter 1 [16].
Further reading (for the curious student). The deep connection between type systems and formal logic – types correspond to propositions, programs to proofs, program reduction to proof normalisation – is the Curry-Howard correspondence. Wadler’s ACM lecture “Propositions as Types” [21] is a short, entry-level survey; Sørensen and Urzyczyn’s book-length Lectures on the Curry-Howard Isomorphism [22] is the standard textbook. These are not required reading for Gazprea, but students designing their own type systems in future courses typically encounter them.
- undefined behavior
“Behavior … for which this document imposes no requirements” [2]. A program exhibiting undefined behavior at run time is not obliged to signal an error, terminate, or produce any particular output. Contrast unspecified behavior and implementation-defined behavior.
- unspecified behavior
“Use of an unspecified value, or other behavior where this document provides two or more possibilities and imposes no further requirements on which is chosen in any instance” [2].
- value category
“Every expression belongs to exactly one of the fundamental categories in [the C++] taxonomy: lvalue, xvalue, or prvalue. This property of an expression is called its value category” [3]. A non-normative overview lives at [23].
- well-formed
“C++ program constructed according to the syntax rules, diagnosable semantic rules, and the one-definition rule” [4]. Gazprea uses “well-formed” throughout in this generalised sense: a Gazprea program is well-formed if it satisfies every diagnosable rule stated in this specification.
- xvalue
An “expiring” value: “a glvalue that denotes an object whose resources can be reused (usually because it is near the end of its lifetime)” [3]. One of the three C++11 value categories. See the non-normative summary at [23] for an accessible introduction.
20.3. On writing glossaries
The structure of this page follows established documentation practice. The Diataxis framework classifies a glossary as reference documentation, whose job is to describe – accurately, austerely, and without narrative – the technical vocabulary of a system [24]. The Write the Docs community guide reiterates the constraint that reference material should be optimised for lookup rather than for narrative reading [25]. Guidance on the craft of glossary-writing itself – one entry per concept, plain language, definitions that do not re-use the word being defined, and concrete examples where possible – is summarised by Lester at The Word Factory [26]. ISO/IEC/IEEE 26514:2022 gives the formal standards-track requirements for user documentation, including terminology sections [27].