CS 641 Lecture -*- Outline -*- * course summary ** review of syllabus ------------------------------------------ WHAT WE STUDIED Overview of Programming Languages Object-Oriented Programming Smalltalk, Java case study Functional Programming Haskell Logic Programming \Prolog ------------------------------------------ Q: What's the importance of each of each? ** Programming lessons Q: What did you learn about programming from each? ------------------------------------------ WHAT DID WE LEARN ABOUT EACH PARADIGM? ------------------------------------------ *** OO (Smalltalk, C++, Java): the utility of data abstraction information hiding (keep rep details in their place) think about types the power of subtype polymorphism (message passing and subclasses) want to define a general vocabulary for organizing ADTs convenience of inheritance for making changes without editing allow for change *** Functional (Haskell, SML, Scheme): how to write recursive functions base, inductive case make program structure match structure of data power of functional abstraction: never write the same thing twice functions as data lazy evaluation monads for encapsulating side effects *** Logic (\Prolog, Prolog): run-time efficiency isn't the only thing want to write programs efficiently too constructive definitions can be turned into programs backtracking unification can represent data by terms *** Comparison Q: What are the advantages and disadvantages (limits) of each paradigm? (see also the styles-vs-problems.txt file) ** language design ideas ------------------------------------------ WHAT DID WE LEARN ABOUT LANGUAGE DESIGN? ------------------------------------------ Q: What principles? regularity, uniformity Q: What techniques? lazy evaluation and blocks ** semantic concepts and ideas ------------------------------------------ WHAT DID WE LEARN ABOUT SEMANTICS? ------------------------------------------ *** Semantic paradigms Q: What semantic paradigms did we study? Q: And what skills did we learn from them? **** Operational semantics (not in Fall 97) recursion on abstract syntax how recursion in programs is modeled (see concepts below) **** Type checking type checking as a kind of simple verification how to infer complex/polymorphic types in programming useful even in untyped languages by name type checking as a means of attaching properties to data **** Denotational semantics (not in 1997): how to simulate state in a functional setting doing the simulation of state shows what's happening compositionality using functions as data *** semantic ideas Q: What are the key semantic ideas or concepts? **** environments shows up in type checking and all kinds of semantics scoping of identifiers separation from store (memory) **** store basic trick in semantics is to pass this around (threading) *** parameter mechanisms call by name, text, value, result, value-result... **** others *** what's the good of this? **** prototyping the language design specification can be read as design of a simple interpreter Q: what gets left unsaid in such a specification? **** the value of formal specification precision when defining a language you want others to implement guide to the concepts to explain semantic techniques allow precision, specification without ambiguity. e.g., Algol 60 report, widely believed to be a model of clarity and clear use of English. says order of evaluation of subscripts should be "from left to right" But what about: A[i + B[f(a)] + g(a)] ? ** some relationships *** semantics and programming help each other interpreters and compilers based on semantics \Prolog ideas probably useful in operational semantics and vice versa e.g., higher-order abstract syntax in programs/semantics reflexive transitive closure of little step semantics. denotational ideas useful in Haskell *** operational and denotational semantics (skip) **** specif and impl. can consider operational sematics to be a model of an implementation, and thus the denotational sematics to be the specification. This leads to questions of the correctness of the implementation, how to prove that etc. **** full abstraction (see Gunter's 6.1) The behavior of a phrase is what it does in various program contexts. Let C[] be a context, and C[P] be a substitution (allowing capture) of P into (the "holes" in) C[]. Consider a denotational semantics M and an operational semantics O. def: P is behaviorally equivalent to P' if for all contexts C[], Let P ~ P' if for all contexts C[], O[[ C[P] ]] = O[[ C[P'] ]] def: a denotational semantics, M, is fully abstract with respect to the opeational semantics, O, iff P ~ P' iff M[[P]] = M[[P']]. That is, full abstraction says that the denotational semantics provides a sound and complete way to reason about behavioral equivalence. ** where to go from here ------------------------------------------ WHERE TO GO FROM HERE Other kinds of programming: - constraint-based - parallel: dataflow (~ functional), data-parallel, distributed, ... Other kinds of semantics: - denotational - algebraic - axiomatic (predicate transformers) Other aspects of semantics: - control flow continuations - semantics of OO programming constructs - new kinds of languages Further classes: - 542 (Programming Languages II) - 641 (Semantic models for Prog. Langs.) ------------------------------------------ ** what's the value of all this? ------------------------------------------ WHAT'S THE VALUE OF ALL THIS? Everything is programming: - even semantics - all transformations of information There are many different styles - you can even use these styles in the same program - program with a style, into a language Everything has syntax and semantics: - even programs - even functions - a helpful first cut at explanations ------------------------------------------