4 ;;Quote: interfaces in Modula-2 worked well: i.e., declarations that reveal the public parts of a module. A module imports the interfaces it uses and exports those it implements

4 ;;Quote: interfaces are better than include files; prevent shortcuts across abstraction boundaries. It is too easy to change the meaning of an include file

5 ;;Quote: the object-oriented abstract type is a bigger building block than a module interface, procedure, statement, or instruction

5 ;;Quote: the partially opaque type reveals some of an object's fields in its interface; e.g., used for I/O streams

6 ;;Quote: a generic module in Module-3 only takes interfaces as parameters; independent, typechecked compilation

7 ;;Quote: a language feature is unsafe if its misuse can corrupt the runtime system; e.g., array assignment without bounds checking

7+;;Quote: an error in a safe program can only cause a run-time error, a wrong answer, or an infinite loop

7+;;Quote: safe programs can share the same address space; no accidental side effects from other programs

7 ;;Quote: the lowest level of a system is not safe; e.g., bus addresses for an I/O controller

7+;;Quote: Modula-3 and Cedar distinguish safe modules from unsafe ones; in the later, programmers must avoid memory corruption

8 ;;Quote: dangling pointers and storage leaks tend to persist long after other errors are removed; prevent with garbage collection

8+;;Quote: Modula-3 always uses garbage collection of traced references in safe modules

8 ;;Quote: garbage collection simplifies interfaces; neither client nor implementation frees allocated references; e.g., Modula-3's required interface for Text

8 ;;Quote: Modula-3 provides unsafe, untraced reference types with an explicit dispose

9 ;;Quote: strong typing is difficult to define simply; e.g., inconsistent subtyping, operator overloading, ambiguous types for literals, target typing, automatic conversions that lose information

9 ;;Quote: in Modula-3 every expression has a unique type with a simple subtype relation

9+;;Quote: Modula-3 does not use ambiguous types, target-typing, or automatic conversions (except for packed fields, etc.)

9 ;;Quote: a language is too complicated if a precise, readable definition requires more than 50 pages

9+;;Quote: keep a language simple by meeting a fixed, page count, complexity budget; helps prune otherwise good ideas

221 ;;Quote: in modern type theory, types are values in a suitable semantic domain; type constructors are maps from this domain into itself

221+;;Quote: with name equivalence, a type only has meaning in a particular program; causes problems for distributed systems and persistent data; simple changes can undo pickled representations

221+;;Quote: with structural equivalence, types are referentially transparent

227 ;;Quote: a brand can appear only once in a program; prevents access from a typecase to the representation of a branded, opaque type

237 ;;Quote: allowing the subtype relation to extend to procedures contravariantly interacts badly with subtype rules that require a change of representation

237+;;Quote: Modula-3 does not extend the subtype relation to procedures, arrays, or sets

242 ;;Quote: Modula-3's generics interact with interfaces and modules, not with the type system; avoids complications of every construct accepting every kind of entity as a parameter

243 ;;Quote: in the theory of dependent types, Modula-3's generic interface is a function from module-values to module-types and a generic module is a function from module-values to module-values