Supportive Features of Programming Languages

Analysis Requirements & Principles architecture:
Paradigms		 substance:
Abstractions		 structure:
Domains 		building blocks: Features
foundational
flexibilized
safety
surface:
Syntactics		 Defining PLs Language
List

  1. The Language Design Space
  2. Empirical Results on Language Features
  3. Decomposition / Structuring / Code Management
  4. Datavalues: Constructors And Types
  5. Other Language Features

 
The focus is on individual features (c.f. their integration).

If you know further references, please don't hesitate to tell me (Ulf Schünemann), likewise if you have any suggestions.

The Language Design Space

Orthogonal features span a language design space. Some orthogonality results:
Feature Result Reference
let + lambda Untyped LC can (macro-)express an additional let. Typed LC can express but not macro-express an additional (polymophic) let. (But don't forget the lexical coherence) [EPL, 13,18,21]
call-by-name/-value Call-by-name and call-by-value LC cannot (macro-)express each other. Call-by-name LC + a construct for strict evaluation can express call-by-value LC. [EPL, 15/20,23]
lazy values Pure Scheme can macro-express lazy constructors (that are not first-class functions). [EPL, 35]
pairs Simply typed LC cannot express the polymophic pair-operations cons, car, cdr. [EPL, 20]
assignment Pure Scheme cannot express assignment and letrec. [EPL, 33]
system ``interactive programming systems actually add expressive power to the programming language'' [EPL, 30]
assignment and procedures ? Weeks, Felleisen: On the orthogonality of assignments and procedures in Algol; POPL 93. dvi ps
lambda + record Lambda abstractions and records are orthogonal to each other and to the core imperative language. [STPL, 155f]
local procedures + objects local procedures (closed over local state) passed to the outside can express objects Goguen? ...
mutability + delayed evaluation ``As far as anyone knows, mutability and delayed evaluation do not mix well in programming languages'' [SICP, at end of 3.5.4]

Empirical Results on Language Features

Empirical research can unreveal the preferences of features (distribution of usage), how and what-for a feature is used and the frequency of errors (error-proneness) in its usage.
8 studies on the advantages of OO programming are reviewed in "A Review of Experimental Investigations into Object-Oriented Technology" by Ignatios S Deligiannis & Martin Shepperd, 1999.
To learn how to do empirical research and some results look at the Empirical Foundations of Computer Science (EFoCS) group at the University of Strathclyde. Also there: Algorithms Problems Empirical Studies (APES)
Feature/Property Result Conclusion Reference
control constructs:
structured usage 		Even before structured programming: 90% of real-world Fortran77 programs and all of 50 large Fortran66 programs have structured control flow. Controlflows that cannot be created by structured programming are infrequent pg 196/7 in: Muchnick: Advanced Compiler Design and Implementation; Kaufmann, 1997.
control constructs:
errors in use 		... While-do better than repeat-until Hildebrand, Reepmeyer: Repeat-Statement considered harmful? -- Ergebnisse einer empirischen Untersuchung; In: Informatik Spektrum 19/2; Springer, 1996.
parameters:
number 		``Weicker found that the average number of arguments to a procedure is about 2, and other studies have substantially agreed with that result...'' ? pg 121 in: Muchnick: Advanced Compiler Design and Implementation; Kaufmann, 1997.
const variables:
ratio of use 		25-35%? of local variables in 5? C++ and 2? Ada libraries are only assigned once (semantically a constant). Only 1%??? of them are declared as const/constant. Declaring local variables as constant is an underestimated feature Schilling: Dynamically valued constants -- An Underused Language Feature In: SIGPLAN Notices 30/4; ACM, 1995.
inheritance:
depth<->
maintainability 		(from [*]) Experiment: Maintaining/modifying OO SW with 3 levels of inheritance depth significantly quicker than OB SW with no inheritance. Maintaining/modifying OO SW with 5 levels of inheritance depth was outperformed (no statistical significance) by OB SW. (from [*]) Attempts to verify the results should be made... Should seek to scale up the findings to the maintenance of more complex software by professional programmers. [*] Daly, Brooks, Miller, Roper, Wood: An Empirical Study Evaluating Depth of Inheritance on the Maintainability of Object-Oriented Software; 95
and: Evaluating Inheritance Depth on the Maintainability of Object-Oriented Software; Empirical Software Engineering; Vol. 1, No. 2, 1996, pages 109-132.
and: The Effect of Inheritance on the Maintainability of Object-Oriented Software: An Empirical Study; Proceedings of the IEEE International Conference on Software Maintenance; October, 1995, pages 20-29.
and: Evaluating the Effect of Inheritance on the Maintainability of Object-Oriented Software; Empirical studies of programmers: sixth workshop; January, 1996, pages 39-58.
? ? ? Miller, Roper, Wood: Empirical Investigation into the Effects of Object-Oriented Technology on Maintenance; Proceedings of the 2nd International Workshop on Empirical Studies of Software Maintenance.
Miller, Darroch, Wood, Brooks, Roper: Changing Programming Paradigm - An Empirical Investigation; Software Quality and Productivity; 1994, pages 62-65.

Decomposition / Structuring / Code Management

C.f. architectural perspectives.

Code Management Concepts (non-manifest structure)

First, we structure the code of a system into some conceptual units (with names) that are not expressed by (defined in) one contingeous piece of code.
Concept Constructs .
TODO for BETA
 TODO .
Clusters for Eiffel:
Open groups of classes. 		TODO .
Packages in Java:
Open groups of classes and packages. Classes/class-members of ``package-level'' access control can be accessed by all classes in the package.
  • xxx.yyy names class/package yyy in package xxx.
  • package xxx.yyy; at the beginning of a file adds package yyy to package xxx (if not already there), and adds all classes defined in the file to package xxx.yyy.
    		• .
    Namespaces in C++:
    Open groups of definitions (classes, functions, namespaces). Definitions in a namespace shared access to the ``unnamed namespace'' within that namespace.
  • xxx::yyy names yyy in namespace xxx.
  • namespace yyy { ... } adds namespace yyy to the current namespace (if not already there), and the names defined between the brackets to namespace xxx::yyy.
    		• .

    Dynamic Structures

    There are different ways of decomposing a running system into sub-systems. These dynamic sub-systems are not expressed (defined) by one piece of code, or not even supported by any feature in the language.
    Concept Constructs Reference
    Subsystems:
    Groups of objects and subsystems. They have characteristics similar to objects (ID etc).     		(Cadet, not a construct) Bicarregui, Lano, Maibaum: Objects, Associations and Subsystems: A Hierarchical Approach to Encapsulation; ECOOP'97.
    Ensembles:
    Groups of objects and ensembles. They have characteristics similar to objects, and possible internal parallelism.     		(Cadet, not a construct) Champeaux: Object-oriented analysis and top-down software development; ECOOP'91.
    Groups:
    Groups of objects with related purpose.     		(Cadet, not a construct) [OGrp] Doug Lea: Objects in Groups.
    ? connectors define component interaction (different kinds)
    In the FLO system: enforce behavior of a group of objects by controlling message passing.
    (+) Allows to express framework architecture and design patterns.     		FLO: [MPA]

    Code Decomposition (manifest structure)

    C.f. code layout features
    Feature Description Argument
    modules (in OO)

  • Szyperski: Import is not inheritance; why we need both: Modules and classes; ECOOP'92.
  • [LOOM Modules] Bruce, Petersen, Vanderwaart: Modules in LOOM: Classes are not enough; 1998.
  • group code into managable pieces with own name-spaces
  • = abstraction barrier around declarations fitting together logically (e.g. mutually recursive classes or ``friend'' classes)
  • = units of compilation
    [LOOM Modules]
    		• (+) ``[C]lasses are too fine a unit to serve usefully as module boundaries ... [M]odules should be used to group together interrelated systems of classes'' [LOOM Modules]
    (-) ``[M]odules are too limiting to be useful in defining the structure of many ... applications. Strict module containment results in static, ``pyramidal'' architectures, and cannot capture the fluidity of most OO designs.'' [OGrp]
    inner classes

    In BETA: See Papers
    Specification for Java: Inner Classes

    		instance of inner class can access variables of the instance of the enclosing class --
    recursion, loop (you know what that is) Are a hinderance to parallelization (also in functional PLs) [ParDivConq]
    parallel divide-and-conquer

    [ParDivConq] Axford: An Elementary Language Construct for Parallel Programming; SIGPLAN Notices 25/7; 1990.

    		A general divide-and-conquer construct replaces loops and recursion Allows better automatic parallelization. Unfamiliar style of programming. Can be similar to real-life parallelization.
    nested procedure block structure . «The benefits of block structure and procedure nesting have been questioned from time to time; see [
    WA Wulf, M Shaw: Global variables considered harmful; 80-86: ACM SIGPLAN Notices 8:2; Feb 1973.
    LA Clark; JC Wilden, L Wolf: Nesting in Ada is for the birds; 139-145: ACM SIGPLAN Notices 15:1; Nov 1980.
    DR Henson: Is block structure necessary? 853-866: Software Practice and Experience 11; 1981.     ]» [Sethi 202]

    Value Constructors And Type Constructors

    See also the Taxonomy of Datatype Categories. W.r.t. types, this section here is only about types of values created from associated constructors; for types separate from the construction of it values see typing.
    Feature Description Argument
    New Type Names for new sets of old values (computationally redundant, for typing purposes only)
    subrange types ... ...
    intersection type of existing types (halotypes)
    [FCCA] Michael C Feathers: Factoring Class Capabilities with Adjectives; JOOP Mar/Apr 1999.     		The intersection of two types is the smallest supertype of either type (cf. intersection types). For example, a "halotype" [FCCA] interface H = { A, B, C } is a structural supertype of all types conforming-to (having-as-supertypes) A and B and C. (+) The halotype construct is a structurally transparent intersection supertype => Decoupling.
    Datatypes --- new type name(constructor)s for new value(constructor)s
    enumeration datatypes
    and
    two-valued datatypes

    vs

    embedding as subrange /
    use of set of constants of larger type

    		enumeration datatypes: (small) sets of conceptually related named constants

    C Lins: Programming Without Enumerations in Oberon; SIGPLAN Notices 25/7, 1990.

    		(-) are limited
    (-) better replaced by other idioms
    (-) contribute to verbosity rather than clarity
    (-) complicate language definition
    -> encode as integer constants
    Cf. similar arguments in OOSC/ETL on Eiffel's lack of enumerations
    Arguments made for Java's lack of enumerations?
    two-valued datatypes:
  • On/off-state, only operation: toggle.
  • Boolean (unordered) with logic operations.
  • Bit is a subrange [0,1] of integer (ordered) with numeric operations.

    Meek: Two-Valued Datatypes; SIGPLAN Notices 25/8, 1990.
    The standard for common language-independent data-types (CLID) ISO/IEC JTC1 SC22 WG11.

    		• The (similar) ways of representing values of these types below the language level should have no effect on the programmer (Pascal's Boolean is a bit datatype). Identifying types because the same mathematical model can serve for them is only a more abstract version of identifying them because they have the same representation: "abstract weak typing."
    Boolean can be emedded into integer as a subrange [0,1]

    Boute: A heretical view on type embedding; SIGPLAN Notices 25/1, 1990.
    Sakkinen: On embedding Boolean as a subtype of Integer; SIGPLAN Notices 25/7, 1990.
    Meek:     Two-Valued Datatypes.

    		Pro: No mathematical reason to reject it; yields useful mathematical properties.
    Con: problems with operator precedence; makes boolean constants and operations redundant; deprives programmer of expression his intention; see also two-valued types.
    structured datatype

    in the Alberich PL [Paakki, Karhinen, Silander: Orthogonal Extensions and Reductions; SIGPLAN Notices 25/7, 1990]

    		unifies records and arrays uniformity of type system makes language smaller
    tuple datatype

    For Eiffel: technical note submitted to NICE.
    For Java: ...

    		... (+) multiple result values returned in one
    (+) structural type-equivalence for tuple types
    Values / Value Constructors (Literals)
    literal values

    Proposal to ISO C: Compound Literals

    		? --
    null values

    [ORM8] Terry Halpin: UML Data Models from an ORM Perspective: Part Eight; Conceptual Modelling 1; April 1999

    		``[O]ver twenty kinds of null have been distinguished in the literature'' (not enough for modelling to have only one or two different nulls)

    Other Language Features

    Note: In pure descriptions no argument or rationale is given besides the description of the feature.

    Some proposals describing new features for ISO C can be found in the ISO C Standard.
    Feature Description Argument
    Adverbial programming with HOF in APL

    Berry: Adverbial Programming; SIGPLAN Notices 25/8; 1990.

    		HOF take functions ("verbs") as arguments and produces new ones -- they are "adverbs" in APL jargon [cf. categorial grammar: "adverbs" take one verb and produce a modified one; "conjunctions" take verb plus verb-or-"noun" ...].
    Define what to do when applied to an entire collection.     		Is appropriate for distributed SIMD parallelization. Better than introducing special control constructs.
    private -- parent-based

    C Chambers et.al.: Parents are Shared Parts: Inheritance and Encapsulation in Self; Lisp and Symbolic Computation 4(3); 1991.
    and in [PWoC]

    		A parent object (cf. delegation-based OO) can access private slots of alls its descendents. Object-based private is too strict, class-based not available in delegation-based OO.
    Precursor

    Precursor construct: the revised formal proposal

    		In a method m allows to access the overridden versions of m in base classes. Simplification (w.r.t. Eiffel's renaming)
    pattern matching

    Proposal to Haskell: W Burton, E Meijer, P Sansom, S Thompson, P Wadler: Views: An Extension to Haskell Pattern Matching; 23 Oct 1996.

    		View types in pattern matching allow multiple `logical' constructors to match against real constructors --
    pattern matching + guards

    Proposal to Haskell: S P Jones: A new view of guards; April 1997.

    		a list of pattern-matched expressions (like in list-comprehension) as guards --
    initilialization

    Proposal to ISO C: Designated Initializers

    		? ...
    overloading of juxtaposition

    B Stroustrup: Generalizing Overloading for C++2000, April 1998^).

    		"x y" will lead to call of a multiplication operation. Tradition in mathematics and physics

    Analysis Requirements & Principles Paradigms Abstractions Domains Features foundational safety flexible typing Syntactics Defining PLs Language List
    Ulf Schünemann 101297, 140801