aa r X i v : . [ c s . P L ] J un A Proposal for a Revision of ISO Modula-2
Benjamin Kowarsch, Modula-2 Software Foundation
May 2020 (arXiv.org preprint) ∗ Abstract
The Modula-2 language was first specified in [Wir78] by N. Wirth at
ETH
Z¨urich in1978 and then revised several times. The last revision [Wir88] was published in 1988. Theresulting language reports included ambiguities and lacked a comprehensive standard library.To resolve the ambiguities and specify a comprehensive standard library an ISO/IECworking group was formed and commenced work in 1987. A base standard was then ratifiedand published as IS 10514-1 in 1996 [JTC96]. Several conforming compilers have since beendeveloped. At least five remain available of which at least three are actively maintained andone has been open sourced. Meanwhile, various deficiencies of the standard have becomeapparent but since its publication, no revision and no maintenance has been carried out.This paper discusses some of the deficiencies of IS 10514-1 and proposes a limited revisionthat could be carried out with moderate effort. The scope of the paper has been deliberatelylimited to the core language of the base standard and therefore excludes the standard library. [II20] describes ISO/IEC standardisation procedures, summarised in brief below.
The International Organisation for Standardisation (ISO) and the International ElectrotechnicalCommission (IEC) operate a joint technical committee (JTC1) to develop, publish and maintaininformation technology standards. JTC1 is organised into subcommittees (SC) and workinggroups (WG). The subcommittee for programming languages is JTC1/SC22. The working groupthat developed the ISO Modula-2 standard was JTC1/SC22/WG13. It was disbanded in 2002.
The development and maintenance of ISO/IEC standards is carried out within working groupsby technical experts nominated by national standard bodies wishing to participate and havingmembership in the relevant technical committee or subcommittee.A working group is established by the relevant committee or subcommittee upon request bya national standard body with voting membership in that committee. The request has to besupported by at least four other national standard bodies with voting membership by declaringtheir intent to participate in the new working group.When a working group has completed all its work items, it is either put into stand-by statusfor future maintenance or disbanded. Once a working group has been disbanded it cannot bere-instated. For any maintenance on the standard a new working group must then be established.
Once a working group has been formed, it is required to produce a standard or a revised editionof a standard within no more than 36 months. Once a standard has been published, it is sub-ject to regular reviews every five years and may either be reconfirmed or withdrawn. AlthoughJTC1/SC22 tends to reconfirm standards for which no working group exists to carry out main-tenance, this cannot be taken for granted and such standards could in principle be withdrawnfor lack of experts to carry out a proper review whenever a regular review is due. ∗ A discussion paper by the same author proposing a revision of IS 10514-1 was distributed in 2015 to formerWG13 participants. Propositions in this paper are based on open peer review feedback from the earlier paper.
The primary challenge with a revision of IS 10514-1 is not the technical work itself but theestablishment of a new ISO/IEC working group, in particular the recruitment of collaboratorsto carry out the work. There are three detrimental factors.
One factor is the common perception that participation in standard bodies is both time con-suming and frustrating. Standardisation work is often characterised by re-opening of issues thathad already been resolved, shifting goals and feature creep. This was certainly the case withJTC1/SC22/WG13. The root causes were collaborator turnover and a general lack of projectmanagement, in particular the absence of rigorous definition and guarding of scope.
Another factor is the time and cost of attending face-to-face working group meetings. Suchmeetings are usually held on a rotational basis and require recurring international travel andhotel accommodation which participants have to cover out of their own pockets unless theyparticipate as part of their employment for and on behalf of a larger corporation.
Yet another factor are the prohibitively high membership fees most national standard bodies arenow charging to individuals willing to participate in standardisation work. In many countriesthere are arrangements in place that permit individuals who are faculty members of universities toparticipate in their national standard body without being charged any membership fee. However,in the realm of programming languages, universities are no longer the primary actors. For a fewmainstream programming languages, the actors are large corporations. And for the vast majorityof programming languages and libraries the actors are small non-profit groups within the opensource software movement. The majority of these groups and their collaborators cannot affordthe membership fees charged by national standard bodies.
In order to recruit the expert collaborators required by [II20] to form a new ISO/IEC workinggroup, collaborators must be given assurances that (a) the effort they will have to invest isreasonably limited both in terms of total work hours and elapsed calendar time to completion,(b) there will be no travel involved and (c) there will be no monetary cost to them.
To meet the aforementioned constraints, we propose the following management approach:(1) the size of the working group shall be kept small, ideally no more than five or six collaborators(2) it shall be attempted to negotiate fee waivers for collaborators who are not university staff(3) all deliberations shall be undertaken via email, groupware and teleconferencing(4) the scope of work shall be agreed upfront, once agreed no further items shall be added,it shall be strictly limited to 10–12 (target) plus 2–3 (reserve) work items(5) work items shall be chosen to follow a pareto distribution by estimated work effort,75–80% shall be lowest to moderate effort while 20–25% may be high effort(6) any work item on which no consensus can be reached shall be removed from scope(7) a register of potential future work items shall be maintained for any potential future revision,items removed from scope due to lack of time or consensus may be added to this register(8) all work shall be completed and a draft revision shall be presented for ballot within one year
Copyright c (cid:13)(cid:13)
Copyright c (cid:13)(cid:13)
Proposal for a Revision of ISO Modula-2 3 [Kow18] describes design principles for the maintenance of classical Modula-2 compilers and howthey should be applied, weighted and prioritised. This paper applies the same considerations toIS 10514-1. For clarity, the terms of reference from [Kow18] are reproduced in this section. The following design principles strongly influenced the proposed revisions in this paper:
There should be one and only one syntax form to express any given concept [Dij78].
Syntax should be chosen for readability and comprehensibility by a human reader [Knu84].
Syntax should be consistent. Analogous concepts should be expressed by analogous syntax.
Of any number of possible syntax forms or semantics, the one likely to cause the least astonish-ment for a human reader should be chosen and the alternatives should be discarded [Geo87].
Units of decomposition, such as modules, classes, procedures and functions should have a singlefocus and purpose [Mar09].
Implementation specific details should always be hidden, public access should be denied [Par72].
Facilities that undermine the safety otherwise safeguarded within the language should be segre-gated from other facilities [Wir88, ch.29]. Their use should require an explicit expression of intentby the author and be syntactically recognisable so as to alert the author, maintainer and readerof the possible implications. This applies and extends the principle of least privilege [Sal74].
The primary objectives for the proposed revisions in this paper are:(1) to remove facilities that are harmful, outdated or violate any of [3.1](2) to update IS 10514-1 with essential modern facilities
The objectives given above may from case to case conflict with one another. Which objectiveshould be given preference in the event of a conflict depends on the following factors:(1) the severity of the offending facility (2) the estimated frequency of use of the offending facility (3) the effort to update sources impacted by change or removal of the offending facility It should be noted that whilst the same principles are applied, the conclusions must necessarily be different.Standard revision necessitates change while compiler maintenance must preserve the original specification.
Copyright c (cid:13)(cid:13)
Copyright c (cid:13)(cid:13)
Proposal for a Revision of ISO Modula-2 4The greater the severity of an offending facility , the stronger is the case for change or removal ;the lower the estimated frequency of use and the less the effort to update impacted sources, thestronger the case for change or removal . In the event that the estimated frequency of use ishigh and the effort to update impacted sources is significant, deprecation may be preferable. Terms of mitigation methods used in this paper have well defined meanings:
A warning shall be issued for each and every use of the offending facility . The offending facility shall be replaced with a proposed alternative.
A compiler switch to enable and disable the offending facility shall be provided and it shall bedisabled by default. When it is enabled, a deprecation warning shall be issued for each and everyuse of the offending facility . Support for the offending facility shall be removed altogether.From an educational perspective, the availability of offending facilities promotes bad habits.
Replacement or removal is therefore generally preferable to warning or deprecation . To be used in combination with any of change, deprecation or removal. A conversion programshould be provided that transforms source code that uses offending facilities into semanticallyequivalent source code that complies with the proposed revisions in this paper.
IS 5014-1 specifies lexical alternatives ! , @ , <> , & and ˜ as synonyms for | , ˆ , , AND and
NOT . Synonym symbols ! , @ , <> , & and ˜ shall be removed from IS 10514-1. The availability of alternative symbols is unnecessary and violates SSP [3.1.1].Symbols ! and @ were not part of the original Modula-2 language, they were added in IS10514-1 in the mistaken belief that computer systems with character sets that lacked a verticalbar and caret, i.e. mainframe computers with 6-bit character sets would still be in use. In reality6-bit character sets had already been obsolete for 30 years when IS 10514-1 was published andthere had never been any need for these alternatives in Modula-2.The inequality operator symbol is preferable to its synonym <> because it resembles themathematical inequality symbol = and as a single character symbol it simplifies lexing. Reservedwords AND and
NOT are preferable to their respective synonyms & and ˜ because of consistency:While there are synonyms for AND and
NOT , there is none for OR . Although | could have been usedto denote OR , it is already used to separate case labels and would have introduced ambiguity. In the context of a standard revision, deprecation is a precursor to eventual removal in a subsequent revision.
Copyright c (cid:13)(cid:13)
Copyright c (cid:13)(cid:13)
Proposal for a Revision of ISO Modula-2 5
The proposed revision may render existing source code incompatible with the revised standard.However, affected code may be brought into compliance through lexical transformation , usingregular expressions and a filter program such as sed or awk which would be virtually effortless. IS 10514-1 specifies octal literals suffixed with B for numeric values and C for character values. Octal literals shall be removed from IS 10514-1.
The use of octal numbers in programming languages had already been outdated for 20 yearswhen IS 5014-1 was published. Moreover, the B and C suffixes used to denote octal literals inModula-2 are also legal digits within hexadecimal literals. This unnecessarily complicates lexingand it violates POLA [3.1.4] as it is confusing to human readers of the source code. The built-in
CHR() function can be used instead of octal character code literals. It evaluatesconstant arguments at compile time and accepts both decimal and hexadecimal arguments.
The proposed revision will likely render existing source code incompatible with the revised stan-dard. However, affected code may be brought into compliance through lexical transformation . IS 5014-1 specifies the minus symbol as set difference operator.
The set difference operator shall be changed to the backslash symbol.
The use of the minus symbol as set difference operator is a violation of ISO/IEC 80000-2 whichexplicitly states that the minus symbol should not be used as set difference operator [II19].
Using the minus symbol for set difference is mathematically incorrect, or at best ambiguous. Theproper mathematical symbol for set difference is a reverse solidus, resembling a backslash.(1) A \ B = { x ∈ A | x / ∈ B } (2) A − B = { a − b | a ∈ A ∧ b ∈ B } (3) A \ B = A − B The proposed revision will likely render existing source code incompatible with the revised stan-dard. However, affected code may be brought into compliance through lexical transformation . Due to the ease and simplicity of lexical transformation, whenever lexical transformation is possible, a tran-sitional period has been deemed unnecessary and thus outright removal is considered preferable over deprecation.
Copyright c (cid:13)(cid:13)
Copyright c (cid:13)(cid:13)
Proposal for a Revision of ISO Modula-2 6
IS 10514-1 specifies two alternative syntax forms for multi-dimensional array type declaration.
The long syntax form for multi-dimensional array declaration shall be deprecated . The short syntax form for multi-dimensional array type declaration
TYPE
Matrix =
ARRAY [0 .. Cols], [0 .. Rows]
OF REAL ; is an abbreviation of and thus equivalent to TYPE
Matrix =
ARRAY [0 .. Cols]
OF ARRAY [0 .. Rows]
OF REAL ; The availability of alternative syntax forms is unnecessary and it violates SSP [3.1.1] and SCP[3.1.3]. The long form becomes increasingly impractical when declaring array types of more thantwo or three dimensions. The short form is therefore preferable to the long form.
The proposed revision does not impact the compatibility of legacy sources.
IS 10514-1 lacks a universal type conversion syntax.
A universal type conversion operator :: shall be added to IS 10514-1. Its precedence shall beone level above that of operator NOT and one level below that of parentheses and function calls.It shall permit safe type conversions (a) between character types, (b) between whole numbertypes, (c) between real number types and (d) between whole and real number types. typeConvExpr :=factor ’::’ typeIdent ;
Alternatively – failing to reach consensus – a pervasive universal safe type conversion function
CONV() analogous to function
CAST() but with the above semantics shall be added instead.
In a type safe language with name equivalence such as Modula-2, the assignment of valuesbetween variables of different types is severely restricted by the type regime. It follows that typeconversion becomes an important and frequent operation. A universal type conversion facilityis preferable over type specific conversion functions as it is consistent and simplifies the corelanguage. It thereby reduces mental load for authors and readers of source code.
IS 10514-1 permits the lexical nesting of module declarations within the implementation partsof modules. A module declared within another module is known as a local module.
Local modules shall be deprecated . Copyright c (cid:13)(cid:13)
Local modules shall be deprecated . Copyright c (cid:13)(cid:13)
Proposal for a Revision of ISO Modula-2 7
If there is sufficient reason to delegate certain responsibilities of a library module to a localmodule, then there is also sufficient reason to delegate those responsibilities to a separate librarymodule. There is no reason why a local module should be chosen over a separate library.A local module within a program or library module unnecessarily increases the line countof the module and thus reduces its readability and maintainability. It runs counter to the veryrationale of decomposing source code into separate modules in the first place.Moreover, a test environment for testing a local module must necessarily be provided withinthe hosting module. This further increases clutter and poses the question whether to release themodule with or without the embedded test environment. By contrast, a proper library modulecan be imported into any number of lexically independent test environments.
Local modules should be removed from their enclosing module and provided as proper librarymodules with their own definition and implementation parts. Such library modules may then bemarked for private use [5.4], exclusive to the module they were removed from.
The proposed revision does not impact the compatibility of legacy sources.
IS 10514-1 lacks a facility to mark a library module for private use. A compiler directive shall be added that marks a library module for private use. A warningshall be issued whenever a module so marked is imported into any scope other than that of animplementation part of any of its designated client modules. Implementations may provide apolicy setting or compiler switch to treat these warnings as compilation errors instead. The directive shall be recognised after the module header of a definition module. privModPragma :=’<*’ ’PRIVATETO’ ’=’ clientModuleList ’*>’ ;clientModuleList :=identList ;
This facility supports the deprecation of local modules by restoring the private-use aspect of localmodules which is lost when they are removed from their host modules and converted into librarymodules. The facility is also useful to discourage the direct use of lower-level library modules,especially when their
API is considered unstable and subject to frequent changes.
IS 10514-1 lacks a facility to mark a definition module as a foreign definition module . A compiler directive to mark a definition module as a foreign definition module shall be added .Implementations that provide means to interface to foreign APIs shall implement the directive. Copyright c (cid:13)(cid:13)
IS 10514-1 lacks a facility to mark a definition module as a foreign definition module . A compiler directive to mark a definition module as a foreign definition module shall be added .Implementations that provide means to interface to foreign APIs shall implement the directive. Copyright c (cid:13)(cid:13)
Proposal for a Revision of ISO Modula-2 8
The directive shall be recognised after the module header of a foreign definition module. ffiPragma :=’<*’ ’FFI’ ’=’ ’"’ foreignAPI ’"’ ’*>’ ;foreignAPI :=’ASM’ | ’C’ | ’Fortran’ | ’Pascal’ | ... ;
A standardised syntax for marking foreign definition modules is a requirement for source codecompatibility across different implementations.
IS 10514-1 lacks a large unsigned type.
A pervasive large unsigned type
LONGCARD shall be added . The range of the type shall be largeenough to express the highest address of the addressable memory of the underlying architecture.
For indices of modern filesystems and databases, a large unsigned type is an absolute requirement.Many existing Modula-2 implementations provide a
LONGCARD type as a language extension.
IS 10514-1 lacks a dedicated Unicode character type.
A dedicated pervasive Unicode character type
UNICHAR shall be added . The type shall be ableto represent all Unicode code points and its internal representation shall use UCS-4 encoding.
Universal international character sets were in their infancy when IS 10514-1 was developed.Meanwhile, use of the Unicode standard [Uni19] has become ubiquitous. Most programminglanguages now provide both a conventional 7-bit or 8-bit character type and an extended 16-bitor 32-bit Unicode character type.
IS 10514-1 lacks a constructor function for values of type
UNICHAR . A pervasive function
UCHR() to return a value of type
UNICHAR for a given code point of type
LONGCARD shall be added . This is analogous to existing function
CHR() in support of type
CHAR . The introduction of type
UNICHAR necessitates a constructor function in support of the new type.
IS 10514-1 specifies conversion functions
INT() , CARD() , FLOAT() , LFLOAT() , TRUNC() and
VAL() . Copyright c (cid:13)(cid:13)
VAL() . Copyright c (cid:13)(cid:13)
Proposal for a Revision of ISO Modula-2 9
Pervasive functions
INT() , CARD() , FLOAT() , LFLOAT() , TRUNC() and
VAL() shall be removed . The universal type conversion facility proposed in [5.2] replaces type specific conversion functions.Moreover, there are serious problems with the aforementioned functions. Their naming andpurpose is inconsistent and confusing, violating SCP [3.1.3], POLA [3.1.4] and SRP [3.1.5].While functions
INT() and
CARD() are named for their return types, functions
FLOAT() , LFLOAT() , TRUNC() and
VAL() are not. Functions
FLOAT() and
LFLOAT() are confusingly named since theirreturn types are
REAL and
LONGREAL . IS 10514-1 does not mandate how the real number types areto be implemented. An implementation may or may not implement them as floating point num-bers. The use of identifiers that suggest a floating point implementation is therefore incorrectand misleading.Function
TRUNC() represents both a conversion function and mathematical function trunc ( x ).Its primary purpose is conversion, not truncation. However, its name indicates truncation, notconversion. The name of a function whose purpose is conversion should indicate conversion andthe function should ideally perform conversion only.Conversely, the name of a function whose purpose is truncation should indicate truncationand the function should strictly perform truncation only. Such a function would then be moreappropriately provided by a math library. It is worthwhile noting that trunc ( x ) is a relic of earlyone’s complement hardware, since replaced by entier ( x ) on modern two’s complement hardwarewhere truncation is less efficient and leads to the accumulation of rounding errors [Tuc04]. Thus,if any pervasive function of this kind is desired, it should be ENTIER() but not
TRUNC() .Finally, function
VAL() has the worst possible naming of all. Instead of indicating conversionin its name, it indicates that it returns a value. However, this is is entirely meaningless since allfunctions return values. The name carries no information about the function’s purpose at all.
It should be noted that we do not propose to remove functions
CHR() and
ORD() because they areare not conversion functions. Character types do not represent numeric values and consequentlythere is no conversion between character types and numeric types. Instead,
CHR() is a lookupfunction that looks up a character by numeric index. Function
ORD() performs a reverse lookup.
The proposed revision will likely render existing source code incompatible with the revised stan-dard. Affected code may be brought into compliance through syntactical transformation . NIL is not compatible with opaque pointer types and procedure types.
NIL shall be compatible with opaque pointer types and procedure types.
The definition of type specific nil values for every opaque pointer type and procedure typeunnecessarily increases code clutter and mental load. No type safety is gained by this restriction.
The proposed revision does not impact the compatibility of legacy sources. entier ( x ) rounds towards −∞ while trunc ( x ) rounds towards 0. Copyright c (cid:13)(cid:13)
The proposed revision does not impact the compatibility of legacy sources. entier ( x ) rounds towards −∞ while trunc ( x ) rounds towards 0. Copyright c (cid:13)(cid:13)
Proposal for a Revision of ISO Modula-2 10
Function
CAST() does not accept constant arguments.
Function
CAST() shall accept constant arguments.
The definition of intermediate variables and assignment of constant values for the sole purpose ofcasting the values unnecessarily increases code clutter and mental load. No type safety is gained.
The proposed revision does not impact the compatibility of legacy sources.
IS 10514-1 does not require pointer variables to be initialised.
All pointer variables shall be initialised to
NIL and deallocation should reset them to
NIL . The two primary paradigms of Modula-2 are (a) program decomposition through data encapsu-lation and information hiding, and (b) reliability through type safety. Opaque pointer types arethe primary instrument through which the former is achieved. The ability to test whether anopaque pointer type has been allocated or deallocated is central to achieving the latter.
The proposed mitigation does not impact the compatibility of legacy sources.
IS 10514-1 permits write access to imported variables.
Write access to imported variables shall be deprecated . Write access to to imported variables violates POIH [3.1.6]. The original Modula-2 languagereport [Wir88, p.88] states that “imported variables should be treated as ‘read-only’ objects”. The proposed mitigation does not impact the compatibility of legacy sources.
Function
SHIFT() is restricted to operate on values of
BITSET types.
Function
SHIFT() shall operate on values of any 8-, 16-, 32- and, if available 64-bit type. Unfortunately, Wirth did not implement this guideline in any of his compilers.
Copyright c (cid:13)(cid:13)
Copyright c (cid:13)(cid:13)
Proposal for a Revision of ISO Modula-2 11
The restriction is entirely impractical because it is most likely to require casting from the originaltype to a
BITSET type before the shift operation and then casting the result back to the originaltype afterwards. This unnecessarily increases clutter and makes the source code difficult to readand maintain. Let us consider the example of a real world hash function below:
PROCEDURE valueForNextChar ( hash : Key; ch :
CHAR ) : Key;
BEGINRETURN
CAST(Key,
ORD (ch)) +CAST(Key, SHIFT(CAST(BITSET32, (hash)), 6)) +CAST(Key, SHIFT(CAST(BITSET32, (hash)), 16)) − hash; END valueForNextChar;
This function body would be far more readable without the casting:
RETURN ORD (ch) + SHIFT(hash, 6) + SHIFT(hash, 16) − hash; The
SHIFT() function has been placed in pseudo-module
SYSTEM for a reason: Facilities providedby
SYSTEM are by their very definition unsafe. Any import and use of function
SHIFT() therebyconstitutes a deliberate decision by the developer to break type safety. No type safety is gainedby restricting the argument types for what is already an unsafe operation.
The proposed revision does not impact the compatibility of legacy sources.
IS 10514-1 specifies records with variant fields, also known as variant records.
Variant record types shall be removed from IS 10514-1 and replaced with type safe extensiblerecord types described in [Wir90]. Slightly deviating from [Wir90], a record type shall only beextensible if its declaration includes a base type specifier. The declaration of an extensible recordtype that does not extend another type shall specify
NIL as its base type.Also deviating from [Wir90], there shall be no special type guard syntax. Instead, the
CASE statement alone shall be used to implement type guards.
CASE record OF | TypeA : ( ∗ access to fields unique to TypeA ∗ ) | TypeB : ( ∗ access to fields unique to TypeB ∗ )( ∗ etc ∗ ) recordType :=TYPE Ident ’=’ RECORD ( ’(’ baseType ’)’ )? fieldListSeq END ;baseType :=’NIL’ | typeIdent ; Variant records permit writing a variant field as one variant and then reading it back as another.This constitutes a hidden type cast and is thus an unsafe operation. The availability of unsafeoperations without prior import from pseudo-module
SYSTEM is a violation of SPP [3.1.7].Furthermore, variant record types are fragile. Whenever another variant is added to a variantfield list, all existing client modules have to be recompiled, This is known as the fragile base classproblem [Mik98]. Variant records are therefore not an adequate facility for software extensibility.By contrast, extensible record types are type safe and they permit non-fragile extension.
The proposed revision will likely render existing source code incompatible with the revised stan-dard. Affected code may be brought into compliance through syntactical transformation . Copyright c (cid:13)(cid:13)
The proposed revision will likely render existing source code incompatible with the revised stan-dard. Affected code may be brought into compliance through syntactical transformation . Copyright c (cid:13)(cid:13)
Proposal for a Revision of ISO Modula-2 12
Definitions
API
Application programming interface. compiler directive
A directive within the source to instruct a language processor how to process the input.
ETH
Eidgen¨ossisch Technische Hochschule – Swiss Federal Institute of Technology . foreign API An API implemented in a language other than Modula-2. foreign definition module
A definition module that specifies an interface to a foreign API . offending facility A language facility that is (a) outdated, harmful or bad habit forming in general,or (b) violates any of the design principles in section 3.1 in particular.
References [Par72] David L. Parnas. On the Criteria to be Used in Decomposing Systems into Modules.
Comunications of the ACM , 15(12), 1972.[Sal74] Jerome H. Saltzer. The Protection of Information in Computer Systems.
Comunications of the ACM , 17(7), 1974.[Dij78] Edsger W. Dijkstra.
On the GREEN Language submitted to the DoD .E.W.Dijkstra Archive, originally circulated privately, 1978.[Wir78] Niklaus Wirth.
Modula-2 . Technical report, ETH Z¨urich, 1978.[Knu84] Donald E. Knuth. Literate Programming.
The Computer Journal , 27(2), 1984.[Geo87] James Geoffrey.
The Tao of Programming . InfoBooks, 1987.[Wir88] Niklaus Wirth.
Programming in Modula-2 . Springer, Heidelberg, 4th edition, 1988.[Wir90] Niklaus Wirth.
Oberon Language Report . Technical report, ETH Z¨urich, 1990.[JTC96] ISO/IEC JTC1/SC22/WG13. Information Technology – Programming Languages –Part 1: Modula-2, Base Language.
International Standard 10514-1 , ISO/IEC, 1996.[Mik98] Leonid Mikhailov and Emil Sekerinski. A Study of the Fragile base Class Problem.Proceedings of the European Conference on Object-Oriented Programming (ECOOP),
Lecture Notes in Computer Science , Springer, 1998.[Tuc04] Allan B. Tucker.
Computer Science Handbook . Chapman & Hall, 2nd Edition, 2004.[Mar09] Robert C. Martin.
Clean Code: A Handbook of Agile Software Craftsmanship .Prentice Hall, 2009.[Kow18] Benjamin Kowarsch.
On the Maintenance of Classic Modula-2 Compilers .Technical report, Modula-2 Software Foundation, 2018.[II19] ISO/IEC. Quantites and units – Part 2: Mathematics.
International Standard ISO/IEC 80000-2,
ISO/IEC, 2019.[Uni19] The Unicode Consortium.
The Unicode Standard .ISBN 978-1-936213-25-2. Unicode Consortium, Version 12.1, 2019.[II20] ISO/IEC.
ISO/IEC Directives . ISO/IEC, 16th edition, 2020. Originally founded as
Federal Polytechnic School , it is still known in English as
Z¨urich Polytechnic . Copyright c (cid:13)(cid:13)