Abstract Data Type

An abstract data type, or ADT, is a type whose internal structure and semantics are hidden from the user of the type and has its semantics defined by the library module that provides the ADT.

ADT Library Module

A library module that defines an abstract data type with the same name as its own module identifier is called an ADT library module. Such a module follows the module-as-a-type paradigm.

Auto-Casting, Auto-Casting Parameter

The property of a formal parameter to accept any constant or variable of any data-type to type cast a passed-in actual parameter to the data type of the formal parameter is called auto-casting. There are two kinds: casting to an open array and casting to an address. The parameter is called an auto-casting formal parameter. Auto-casting semantics were first introduced in classic Modula-2 but without any associated terminology.

Binding

Binding is the attachment of attributes to a syntactic entity. While most bindings are language defined and immutable, Modula-2 R10 provides three kinds of bindings that are user-definable.

Binding to Built-in Syntax

A library that implements an abstract data type may define a procedure and bind it to built-in syntax that would otherwise only be available in association with built-in types. The bound-to syntax may then be used with the abstract data type as if it was built-in.

Binding to an Operator

A library that implements an abstract data type may define a procedure and bind it to an operator. The bound-to operator may then be used with the abstract data type as if it was built-in.

Binding to a Predefined Procedure

A library that implements an abstract data type may define a procedure and bind it to the identifier of a pre-defined procedure. The bound-to procedure may then be passed parameters of the abstract data type.

Collection Type, Accessor, Value

A type with an arbitrary number of elements all of which are of the same type is called a collection type. An instance of a collection type is called a collection. The values of a collection are addressable by an accessor. A collection whose values are accessed by index is called an indexed collection or array. A collection whose values are accessed by key is called a key-value collection or dictionary.

Compliance

Full Compliance

An implementation that fully complies with the Modula-2 R10 language specification in every aspect is a fully compliant implementation. A fully compliant implementation that adds syntax, operators, reserved words predefined identifiers, pseudo-modules or language pragmas is a fully compliant superset. It may be domain specific.

Partial Compliance

An implementation that omits any syntax, operators, reserved words, predefined identifiers, pseudo-modules or mandatory language pragmas, but complies with the Modula-2 R10 specification in those parts that it implements is a partially compliant implementation or partially compliant subset. Such a subset may be domain specific.

Non-Compliant Derivative

An implementation that provides any modified syntax, operators, predefined entities, pseudo-modules or language pragmas but is otherwise based on the Modula-2 R10 specification is a non-compliant derivative.

Coordinated and Uncoordinated Superset

A compliant language superset whose additional symbols, reserved words, predefined identifiers or language pragmas have been reserved in the language specification for exclusive use by the superset is a co-ordinated superset. A compliant language superset that is not coordinated is an uncoordinated superset.

Indeterminate Record, Indeterminate Field, Discriminant Field

An indeterminate record is a record with an indeterminate field. An indeterminate field is a record field whose size is determined only at runtime. A discriminant field is a record field that holds the size of an indeterminate field. The indeterminate field is not resizable and the discriminant field has single-assignment semantics.

Module as a Manager, Module as a Type

Under the module-as-a-manager paradigm, a module provides facilities to create, destroy, inspect and manipulate entities of a data type that is not provided by the module itself. Under the module-as-a-type paradigm, a module provides both the type itself and the operations defined for the type.

Mutability and Immutability of Variables

A variable is always mutable when referenced from the scope in which it is declared. However, a variable may be immutable within the context of a different scope than that in which it was declared.

Named Type, Anonymous Type

A named type is a type that has a name associated with it and can be identified by its name which is called its identifier. An anonymous type does not have a name associated with it and it can only be identified by its structure.

Open Array, Open Array Parameter

An open array is an array whose size is not specified. An open array parameter is a formal parameter whose formal type is an open array. In a call to a procedure with an open array parameter, any array of the same dimension and base type may be passed in for the open array parameter.

Parameter

A parameter is an entity to pass data into and possibly out of a procedure or function.

Formal Parameter, Actual Parameter

A parameter defined in the header of a procedure or function is called a formal parameter. A parameter passed in a call to a procedure or function is called an actual parameter.

Predefined, Predefined Identifier

A language defined constant, data type, procedure or function that is visible in any module scope without prior import is said to be predefined and is called a predefined entity. Its identifier is called a predefined identifier.

Pragma

A pragma is an in-source compiler directive that controls or influences the compilation process but does not alter the meaning of the program text in which it appears.

Procedure, Returning a Result in Its Own Name

A procedure is a named sequence of zero or more statements which may be invoked by calling the procedure. Zero or more parameters may be passed in and out of a procedure. A procedure passing a result back to its caller other than by VAR parameter is said to return a result in its own name. There are two kinds of procedures.

Function Procedure

A function procedure is a procedure that returns a result in its own name.

Regular Procedure

A regular procedure is a procedure that does not return result in its own name.

Procedure Signature

The order, types and attributes of the formal parameters of a procedure as well as its return type are collectively called the procedure's signature. The signature of a procedure determines the compatibility of actual and formal parameters when the procedure is called. A procedure signature further determines whether the procedure is compatible with a given procedure type.

Function Signature

The signature of a function procedure is also referred to as a function signature.

Pseudo Entity

A pseudo entity is a built-in syntactic entity with special properties different from those of regular entities.

Pseudo-Module

A pseudo-module is a module that acts and looks like a library module but is built into the language because the facilities it provides would be difficult or impossible to implement outside of the compiler, or because the facilities it provides are unsafe.

Pseudo-Procedure

A pseudo-procedure is a built-in intrinsic or macro that acts and looks like a procedure but is either inlined or its signature may be indeterminate or both. Due to these properties, it may not be passed as a procedure type parameter nor assigned to a procedure type variable.

Pseudo-Type

A pseudo-type is a built-in type whose use is restricted to one or more specific use cases, such as a type that may only be used as a formal type in a formal parameter list.

Soft, Hard and Promotable Compile Time Warnings

A compile time warning is a warning message emitted by a compiler during compile time. Soft compile time warnings may be silenced via compiler settings. Hard compile time warnings may not be silenced. Promotable compile time warnings may be promoted to compile time errors via compiler settings.

Type Equivalence

A regime that determines the equivalence of types is called type equivalence.

Name Equivalence

Under name equivalence, a type is considered equivalent to another if their type identifiers match.

Loose Name Equivalence

Under loose name equivalence it is not possible to distinguish between intended and unintended alias types. An alias of a type is always considered equivalent to its aliased type.

Strict Name Equivalence

Under strict name equivalence it is either possible to distinguish between intended and unintended alias types, or all alias types are not considered equivalent to their aliased types. If intended and unintended alias types are distinguished, then intended alias types are considered equivalent to their aliased types and unintended alias types are not. Strict name equivalence is the safest of all type regimes.

Structural Equivalence

Under structural equivalence, types are considered equivalent if their structures match.

Type Transfer

A type transfer is the transfer of a value from one to another type. There are two kinds of type transfer:

Type Cast

A type cast is a type transfer in which the bit representation of a value is not modified but simply reinterpreted as that of another type. The result of a type cast may or may not correspond to the original value or any approximation thereof. A type cast is therefore unsafe.

Type Conversion

A type conversion is a type transfer by which the bit representation of a value is modified or replaced if necessary in order to obtain an equivalent value that corresponds to the original value or an approximation thereof in another type. The safety of a type conversion is guaranteed by its implementation.

Unsafe, Non-Portable

A feature is unsafe if the language cannot guarantee that a program using the feature will function properly regardless of the runtime environment and target architecture. A feature is non-portable if the language cannot guarantee that a program using the feature will function properly depending on the runtime environment and target architecture.

Unsafe Facility Enabler

Reserved words or pragmas that provide unsafe facilities are unavailable by default and must be enabled by unqualified import of a corresponding unsafe facility enabler from a pseudo-module before they can be used.

Variadic Procedure, Variadic Parameter

A variadic procedure is a procedure that can accept a variable number of parameters. A variadic parameter is a formal parameter for which a variable number of actual parameters may be passed in.

Wirthian Macro

A Wirthian Macro is a language defined lexical macro that acts and looks like a procedure where an invocation of the macro is replaced by a call to a library defined procedure. The list of parameters passed in the invocation does not necessarily match the list of parameters passed in the procedure call that replaces it. One or more parameters may be automatically substituted or inserted. Wirthian Macros first appeared in the form of NEW and DISPOSE in classic Modula-2 but without any associated terminology.