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?