CS 334 Programming Languages Spring 2002 Lecture 25

Criteria for Language Design

1. Writeability

Simplicity

- bad ex: PL/I & Ada - don't throw in kitchen sink!

If too complex, danger of unexpected interactions, subsetting & (if redundant) development of dialects.

Simple conceptual model of semantics.

Can go too far! E.g., Basic, LISP syntax.

"Everything should be as simple as possible, but not simpler" Einstein

Uniformity:

Bad example: subscript vs fcn def in FORTRAN.

Good example: Instance vble vs parameterless function in Eiffel

Expressiveness

Success depends on appl.

Orthogonality & generality

Ex. of probs w/ Pascal: Fcn can only return simple type, constants only defined for built-in basic types, enumerated types cannot be read or written, etc.

Algol 68 carries to extremes, everything has value.

Smalltalk, Eiffel, other pure object-oriented languages do it well.

Clear, unambiguous syntactic and semantic description

Original presentation usually too vague. Refined.

ALGOL 68 problem w/ redefining terms.

2. Readability - Modifiability and Maintenance.

Documentation:

commenting conventions: line vs stream oriented.

Lexical and syntactic conventions:

blocking of compound statements - if, fi versus begin, end

two-dimensional syntax, syntax directed editors.

Not synonymous with wordiness:

Importance depends on number of programmers.

3. Reliability

Related to writeability, readability, and modifiability.

Static checks

Separate (but not independent) compilation

Minor modifications should not require major changes.

Clear semantics supporting verification.

Simplicity of compiler implementation.

Practical Considerations in language choice

4. Fast translation

5. Efficient object code

6. Machine independence:

Hoare on Designing Programming Languages

Features:

Make sure solves problem, without causing new ones.

Show simply and efficiently implemented.

Carefully specify semantics

Use in lots of examples

Language:

Watch for inconsistencies, interactions.

(Knuth article on remaining problems in Algol 60: interactions major theme,
e.g. side effects and order of evaluation, unexpected exit from control structure, aliasing - 2 diff. ways of referring to vble, integers also labels)

Be especially wary of new features

Be ready to make modifications to solve minor problems.

Know intended applications, allowable size and complexity.

Implement on several machines, write manuals and texts

Be prepared to sell it to customers

Don't include untried ideas - consolidation, not innovation.

Make design group as small as possible.

Don't be afraid to revise - once distributed, too hard to change.

Simplicity is really the key - avoid complexity. Too many "solutions" make language hard to understand.

(See also Hoare, "The emperor's old clothes", CACM, Feb., 1981, pp. 75-83.)

Base programming language on:

1. a minimum number of independent concepts combined in a uniform manner.

2. a comprehensive definition mechanism to provide the breadth.

3. a small core language on which the extensions are based.

4. a syntax chosen for its readability.

Most dangerous approach to problems: add new features

Trap PL/I, Ada, and now C++ fell into.

Principles from MacLennan (Programming languages text):

1. Abstraction: Avoid requiring something to be stated more than once; factor out the recurring pattern.

2. Automation: Automate mechanical, tedious, or error-prone activities. (Provide higher level features - e.g. DO loop)

3. Defense in Depth: If an error gets through one line of defense, then it should be caught by the next line of defense. (e.g. if incorrect but syntactically ok, then should fail type-checking - DO, varieties of GOTO in FORTRAN)

4. Information Hiding: Modules should be designed so that: (1) The user has all the information needed to use the module correctly, and nothing more. (2) The implementor has all the information needed to implement the module correctly, and nothing more.

5. Labeling: We should not require the user to know the absolute position of an item in a list. Instead, we should associate labels with any position that must be referenced elsewhere. (E.g., labelled case as opposed to unlabelled)

6. Localized Cost: A user should only pay for what he uses; avoid distributed costs. (Don't build in so much generality that simple things expensive, e.g ALGOL DO, default param's)

7. Manifest Interface: All interfaces must be apparent (manifest) in the syntax. (Clear how to use, no side-effects)

8. Orthogonality: Independent functions should be controlled by independent mechanisms. (Avoid dependencies -e.g. logic and control).

9. Portability: Avoid features or facilities that are dependent on a particular machine or a small class of machines.

10. Preservation of Information: The language should allow the representation of information that the user knows and that the compiler will need. (E.g. DO loops, subrange types - make it easier to optimize.)

11. Regularity: Regular rules, without exceptions, are easier to learn, use, describe, and implement.

12. Security: No program that violates the definition of the language, or its own intended structure, should escape detection.

13. Simplicity: A language should be as simple as possible. There should be a minimum number of concepts with simple rules for their combination.

14. Structure: The static structure of a program should correspond in a simple way with the dynamic structure of the corresponding computations.

15. Syntactic Consistency: Things which look similar should be similar and things which look different should be different.

16. Zero-One-Infinity: The only reasonable numbers in programming language design are zero, one, and infinity. (Avoid special cases, E.g. compound commands in Pascal.)

Why a principles of programming languages course:

Get better understanding of principle features of programming languages.

Explore design space of programming languages.

Introduce different ways of thinking about programming reflected by different programming language paradigms.

The one thing you can count on is change! You need to be able to evaluate new languages for their suitability for the desired purpose and to understand the parameters of the design space and why different choices make sense.

What have we done?

1. Syntax (formal) and semantics (informal and formal) of common programming language concepts.

   Structure of compilers / interpreters. Importance of binding time. Variables: static vs. dynamic scoping, lifetime of variables, l-values vs. r-values.

2. Run-time structure of programming languages. Allocation of storage at run-time. Parameter passing mechanisms. Storage reclamation (explicit - under programmer control, automatic - garbage collection and reference counting).

3. Types in programming languages. Available types and their representation. Type structures in important representative languages.

4. Issues in type-checking: Static vs. dynamic type-checking. Type compatibility (structural vs. name equivalence). Holes in type systems (e.g. variant records). Problems with pointers.

5. Abstract data types and representation in programming languages.

6. Expressions: Order of evaluation (including short-circuit evaluation), functions, and side-effects

7. Control structures (including exception handling).

8. Polymorphism - implicit and explicit.

9. Programming in the large: Support from languages (information hiding, encapsulation, separate but not independent compilation, explicit importing and exporting of environments.)

10. Programming language paradigms:
    1. Imperative: Assignment statements (incl. order of evaluation, side-effects, and aliasing) and control structures. Iterators. Procedures, coroutines.

    2. Functional: Expanded expression constructs. Pattern matching and type inference. Higher-order functions. Lazy vs. eager languages. Recursively defined types. Implementation issues (efficiency and possibility of implementation on highly-parallel computers). Program verification. ML as an example.

    3. Object-oriented: Origins in object-based languages supporting ADT's. Key features: objects and classes, message passing & dynamic method invocation, subclasses and inheritance, subtyping, etc. Support for abstractions and information-hiding. Object-oriented view of algorithms. Support for incremental modification through inheritance and subclasses. Difference between subtyping and inheritance. Type-checking problems in popular languages. Complications in semantics of inheritance. Loss of locality in inheritance.

    4. Concurrency: Semaphores, monitors, CSP, and message passing.

11. Semantics: Operational, Axiomatic, and denotational semantics.

12. Evolution of programming languages. Problems which led to introduction of new constructs.

13. Criteria for language design: Writeability, readability, reliability, efficiency considerations, portability. How to design features and languages. How to choose a language.

Graduate level course would be more formal and have less emphasis on learning individual languages. (Either operational or denotational semantics.)

Hope have better understanding of options open to programmer. How language can support programmer (as well as awareness of traps). Different paradigms represent different ways of thinking about programming (don't expect to have become expert programmers in languages taught).