Modula-2 Reloaded ⋄ Glossary

2015-09-17 15:40 by trijezdci -

Changed line 39 from:

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 a dictionary.

to:

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.

2015-09-17 15:39 by trijezdci -

Changed line 24 from:

A library that implements an [[#ADT|abstract data type]] may define a [[#Procedure|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 [[#ADT|abstract data type]] as it it was built-in.

to:

A library that implements an [[#ADT|abstract data type]] may define a [[#Procedure|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 [[#ADT|abstract data type]] as if it was built-in.

2015-09-17 15:38 by trijezdci -

Changed line 14 from:

The property of a [[#FormalParameter|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 [[#OpenArray|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.

to:

The property of a [[#FormalParameter|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: [[#TypeCast|casting]] to an [[#OpenArray|open array]] and [[#TypeCast|casting]] to an address. The [[#Parameter|parameter]] is called an ''auto-casting formal parameter''. Auto-casting semantics were first introduced in classic Modula-2 but without any associated terminology.

2015-09-17 15:36 by trijezdci -

Changed lines 24-25 from:

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 it it was built-in.

to:

A library that implements an [[#ADT|abstract data type]] may define a [[#Procedure|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 [[#ADT|abstract data type]] as it it was built-in.

Changed lines 29-30 from:

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.

to:

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

Changed lines 34-35 from:

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''.

to:

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

Changed lines 47-48 from:

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.

to:

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, [[#PseudoModule|pseudo-modules]] or language [[#Pragma|pragmas]] is a ''fully compliant'' superset. It may be domain specific.

Changed lines 52-53 from:

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.

to:

An implementation that omits any syntax, operators, reserved words, predefined identifiers, [[#PseudoModule|pseudo-modules]] or mandatory language [[#Pragma|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.

Changed lines 57-58 from:

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''.

to:

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

Changed lines 62-63 from:

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.

to:

A compliant language superset whose additional symbols, reserved words, predefined identifiers or language [[#Pragma|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.

Changed lines 92-93 from:

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

to:

A ''parameter'' is an entity to pass data into and possibly out of a [[#Procedure|procedure]] or [[#FunctionProcedure|function]].

Changed lines 97-98 from:

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 of function is called an ''actual parameter''.

to:

A ''parameter'' defined in the header of a [[#Procedure|procedure]] or [[#FunctionProcedure|function]] is called a ''formal parameter''. A [[#Parameter|parameter]] passed in a call to a [[#Procedure|procedure]] or [[#FunctionProcedure|function]] is called an ''actual parameter''.

Changed lines 102-103 from:

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''.

to:

A language defined constant, data type, [[#Procedure|procedure]] or [[#FunctionProcedure|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''.

Changed lines 117-118 from:

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

to:

A ''function procedure'' is a [[#Procedure|procedure]] that [[#ReturningAResultInItsOwnName|returns a result in its own name]].

Changed lines 122-123 from:

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

to:

A ''regular procedure'' is a [[#Procedure|procedure]] that does '''''not''''' [[#ReturningAResultInItsOwnName|return result in its own name]].

Changed lines 127-128 from:

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.

to:

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 [[#ActualParameter|actual]] and [[#FormalParameter|formal parameters]] when the [[#Procedure|procedure]] is called. A ''procedure signature'' further determines whether the [[#Procedure|procedure]] is compatible with a given procedure type.

Changed lines 132-133 from:

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

to:

The signature of a [[#FunctionProcedure|function procedure]] is also referred to as a ''function signature''.

Changed lines 147-148 from:

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.

to:

A ''pseudo-procedure'' is a built-in intrinsic or macro that acts and looks like a [[#Procedure|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.

Changed lines 152-153 from:

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.

to:

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 [[#FormalParameter|formal parameter]] list.

Changed lines 192-193 from:

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 ~~regarded as~~ ''unsafe''.

to:

A ''type cast'' is a [[#TypeTransfer|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''.

Changed lines 197-198 from:

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.

to:

A ''type conversion'' is a [[#TypeTransfer|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.

Changed lines 207-208 from:

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.

to:

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

Changed lines 212-213 from:

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.

to:

A ''variadic procedure'' is a [[#Procedure|procedure]] that can accept a variable number of [[#Parameter|parameters]]. A ''variadic parameter'' is a [[#FormalParameter|formal parameter]] for which a variable number of [[#ActualParameter|actual parameters]] may be passed in.

Changed line 217 from:

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.

to:

A ''Wirthian Macro'' is a language defined lexical macro that acts and looks like a [[#Procedure|procedure]] where an invocation of the macro is replaced by a call to a library defined [[#Procedure|procedure]]. The list of [[#Parameter|parameters]] passed in the invocation does not necessarily match the list of [[#Parameter|parameters]] passed in the [[#Procedure|procedure]] call that replaces it. One or more [[#Parameter|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.

2015-09-17 15:21 by trijezdci -

Changed lines 9-10 from:

A library module that ~~defined~~ 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.

to:

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

Changed line 14 from:

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.

to:

The property of a [[#FormalParameter|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 [[#OpenArray|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.

2015-09-17 15:18 by trijezdci -

Added line 1:

[[#ADT]][[#AbstractDataType]]

Added line 6:

[[#AdtLibraryModule]]

Added line 11:

[[#AutoCasting]][[#AutoCastingParameter]]

Added line 16:

[[#Binding]]

Added line 21:

[[#BindingToSyntax]]

Added line 26:

[[#BindingToOperator]]

Added line 31:

[[#BindingToMacro]]

Added line 36:

[[#CollectionType]][[#Accessor]][[#Value]]

Added line 41:

[[#Compliance]]

Added line 44:

[[#FullCompliance]]

Added line 49:

[[#PartialCompliance]]

Added line 54:

[[#NonCompliantDerivative]]

Added line 59:

[[#CoordinatedSuperset]][[#UncoordinatedSuperset]]

Added line 64:

[[#IndeterminateRecord]][[#IndeterminateField]][[#DiscriminantField]]

Added line 69:

[[#ModuleAsAManager]][[#ModuleAsAType]]

Added line 74:

[[#MutabilityOfVariables]][[#ImmutabilityOfVariables]]

Added line 79:

[[#NamedType]][[#AnonymousType]]

Added line 84:

[[#OpenArray]][[#OpenArrayParameter]]

Added line 89:

[[#Parameter]]

Added line 94:

[[#FormalParameter]][[#ActualParameter]]

Added line 99:

[[#Predefined]][[#PredefinedIdentifier]]

Added line 104:

[[#Pragma]]

Added line 109:

[[#Procedure]][[#ReturningAResultInItsOwnName]]

Added line 114:

[[#FunctionProcedure]]

Added line 119:

[[#RegularProcedure]]

Added line 124:

[[#ProcedureSignature]]

Added line 129:

[[#FunctionSignature]]

Added line 134:

[[#PseudoEntity]]

Added line 139:

[[#PseudoModule]]

Added line 144:

[[#PseudoProcedure]]

Added line 149:

[[#PseudoType]]

Added line 154:

[[#SoftCompileTimeWarning]][[#HardCompileTimeWarning]][[#PromotableCompileTimeWarning]]

Added line 159:

[[#TypeEquivalence]]

Added line 164:

[[#NameEquivalence]]

Added line 169:

[[#LooseNameEquivalence]]

Added line 174:

[[#StrictNameEquivalence]]

Added line 179:

[[#StructuralEquivalence]]

Added line 184:

[[#TypeTransfer]]

Added line 189:

[[#TypeCast]]

Added line 194:

[[#TypeConversion]]

Added line 199:

[[#Unsafe]][[#NonPortable]]

Added line 204:

[[#UnsafeFacilityEnabler]]

Added line 209:

[[#VariadicProcedure]][[#VariadicParameter]]

Added line 214:

[[#WirthianMacro]]

2015-09-17 14:55 by trijezdci -

Changed line 3 from:

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

to:

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.

2015-09-17 14:53 by trijezdci -

Changed lines 163-164 from:

to:

!!! 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.

2015-09-17 14:47 by trijezdci -

Changed line 161 from:

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.

to:

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.

2015-09-17 14:45 by trijezdci -

Added lines 98-163:

!!!! 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 regarded as ''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.

2015-09-17 14:23 by trijezdci -

Changed lines 53-98 from:

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.

to:

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 of 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 a result in its own name.

2015-09-17 14:08 by trijezdci -

Changed line 53 from:

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 he ''discriminant field'' has single-assignment semantics.

to:

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.

2015-09-17 14:08 by trijezdci -

Changed lines 41-42 from:

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

to:

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 he ''discriminant field'' has single-assignment semantics.

2015-09-17 14:01 by trijezdci -

Changed lines 11-41 from:

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''.

to:

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 it 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 a 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 specification in those parts that it implements is a ''partially compliant'' implementation or ''partially compliant'' subset. Such a subset may be domain specific.

2015-09-17 13:45 by trijezdci -

Added lines 1-12:

!!! Abstract Data Type

An ''abstract data type'', or ADT, is a type whose internal structure an 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 defined 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''.

Modula-2 Reloaded

A Modern Typesafe & Literate Programming Notation

Glossary

Reference.Glossary History