CS 541 Lecture -*- Outline -*-
* Expressive Richness comparisons
** Algebraic view of language design
*** Language has an algebraic (ADT) structure, as does each feature
---------------------
objects (state) + operations (commands)
examples of ADTs
built-in types (integers, arrays)
variables
program counter
language's ADT might be as follows:
basic values (bool, int, location, ...)
expressions (ops work on basic values)
commands (ops are ;, :=, if,
begin decls;exp end
etc.)
---------------------
*** Languages differ in the state and operations they present to users.
** expressiveness of an ADT
(make the connection to Prog Langs)
Ref: Kapur and Mandayam paper (7th POPL, 1980)
*** tradeoffs
expressiveness and simplicity, orthogonality, etc.
e.g., if no statements, it's more simple,
but less useful
when does the design have enough?
*** design for an ADT = interface
set of operations over same set of abstract values
(have to be able to create, distinguish)
----------------------
e.g., immutable sets of natural numbers (set[N])
(1) null, insert, remove, has, empty, max, equal
(2) null, insert, has
(3) null, insert, equal
counterexample (different type):
(4) null, insert, remove, max
----------------------
*** expressive completeness (idea)
----------------------
type is expressively complete iff
functions computable over the type's abstract values
same as functions implementable
from the type's operations
----------------------
e.g., (1) is expressively complete, as is (3).
counterexample: (2) is not expressively complete!
cannot implement remove as a total function.
**** formalize computable over abstract values
by goedelization (encoding/decoding)
and requirement that functions preserve
observable equivalence
**** Note theorem 2 of the paper
(expressive completeness follows if
observable equivalence is implementable and decidable)
unlikely to help
as observable equivalence is undecidable for programs.
*** expressive richness
-------------------
problem: design (3) is expressively complete,
but difficult to use.
e.g., to program remove need to enumerate the sets,
and see if inserting the numeric argument
will result in the given set argument
want to avoid enumeration/encoding as (intuitively)
difficult to program
idea: must be able to extract all information needed to
recreate a value of the type
using the type's operations,
but *without recursion*.
-------------------
e.g., design (1) is expressively rich, since can get
complete info about value using:
empty, max, and remove
and conditional compositions
counterexample: design (3) is not expressively rich
since cannot find size of set without recursion
formalize "all info needed to recreate value"
by distinguished functions
p-functions: tell what constructor applied last
d-functions: undo last constructor
e.g., for design (1) have constructors {null, insert},
d-funs for insert: max, \s.remove(s,max(s))
p-fun for null: empty
p-fun for insert: \s.not(empty(s))
*** Problems, extensions
**** handle built-in types in various languages
(have to extend to ADTs with mutation)
**** extend to types where observable equivalence not decidable
(like procedures, programs, ...)
**** finer grained comparison that accounts for efficiency
(like complexity hier.)
for both ADTs and programming langauges
**** not easy to characterize programs as ADTs (but there is work here).
**** observable equivalence for programs is not decidable,
so theorems do not apply.
**** are programming languages expressively complete as ADTs?
does this even make sense?