1
play

1 A good language design presents abstract Good languages designed - PDF document

CS 242 Thanks! Review Teaching Assistants Mike Cammarano TJ Giuli Hendra Tjahayadi John Mitchell Graders Andrew Adams Tait Larson Kenny Lau Aman Naimat Final Exam


  1. CS 242 Thanks! Review � Teaching Assistants • Mike Cammarano • TJ Giuli • Hendra Tjahayadi John Mitchell � Graders • Andrew Adams Tait Larson • Kenny Lau Aman Naimat Final Exam • Vishal Patel Justin Pettit Wednesday Dec 8 • and more … 8:30 – 11:30 AM Gates B01, B03 Course Goals There are many programming languages � Understand how programming languages work � Early languages • Fortran, Cobol, APL, ... � Appreciate trade-offs in language design � Algol family � Be familiar with basic concepts so you can understand discussions about • Algol 60, Algol 68, Pascal, …, PL/1, … Clu, Ada, Modula, Cedar/Mesa, ... • Language features you haven’t used � Functional languages • Analysis and environment tools • Lisp, FP, SASL, ML, Miranda, Haskell, Scheme, Setl, ... • Implementation costs and program efficiency � Object-oriented languages • Language support for program development • Smalltalk, Self, Cecil, … • Modula-3, Eiffel, Sather, … • C++, Objective C, …. Java General Themes in this Course � Language provides an abstract view of machine � Concurrent languages • We don’t see registers, length of instruction, etc. • Actors, Occam, ... � The right language can make a problem easy; • Pai-Lisp, … wrong language can make a problem hard � Proprietary and special purpose languages • Could have said a lot more about this • TCL, Applescript, Telescript, ... � Language design is full of difficult trade-offs • Postscript, Latex, RTF, … • Expressiveness vs efficiency, ... • Domain-specific language • Important to decide what the language is for � Specification languages • Every feature requires implementation data structures and algorithms • CORBA IDL, ... • Z, VDM, LOTOS, VHDL, … 1

  2. A good language design presents abstract Good languages designed with specific goals (often an intended application) machine, an idealized view of computer • C: systems programming • Lisp: cons cells, read-eval-print loop • Lisp: symbolic computation, automated reasoning • FP: ?? • FP: functional programming, algebraic laws • ML: functions are basic control structure, memory model includes closures and reference cells • ML: theorem proving • C: the underlying machine + abstractions • Clu, ML modules: modular programming • Simula: activation records and stack; object references • Simula: simulation • Smalltalk: objects and methods • Smalltalk: Dynabook, • C++: ?? • C++: add objects to C • Java: Java virtual machine • Java: set-top box, internet programming Design Issues � Language design involves many trade-offs � In general, high-level languages/features are: • space vs. time • slower than lower-level languages – C slower than assembly • efficiency vs. safety – C++ slower than C • efficiency vs. flexibility – Java slower than C++ • efficiency vs. portability • provide for programs that would be • static detection of type errors vs. flexibility difficult/impossible otherwise • simplicity vs. "expressiveness" etc – Microsoft Word in assembly language? � These must be resolved in a manner that is – Extensible virtual environment without objects? – Concurrency control without semaphores or monitors? • consistent with the language design goals • preserves the integrity of abstract machine Many program properties are undecidable Languages are still evolving (can't determine statically ) • Halting problem • Object systems • nil pointer detection • Adoption of garbage collection • alias detection • Concurrency primitives; abstract view of concurrent systems • perfect garbage detection • Domain-specific languages • etc. • Network programming Static type systems • Aspect-oriented programming and many other “fads” • detect (some) program errors statically – Every good idea is a fad until is sticks • can support more efficient implementations • are less flexible than either no type system or a dynamic one 2

  3. Summary of the course Lisp Summary � Lisp, 1960 � Modularity and objects � Successful language • encapsulation • Symbolic computation, experimental programming � Fundamentals • dynamic lookup � Specific language ideas • lambda calculus • subtyping • Expression-oriented: functions and recursion • denotational semantics • inheritance • Lists as basic data structures • functional prog � Simula and Smalltalk • Programs as data, with universal function eval � ML and type systems • Stack implementation of recursion via "public � C++ � Block structure and pushdown list" activation records � Java • Idea of garbage collection. � Exceptions and � Concurrency continuations Fundamentals Algol Family and ML � Grammars, parsing � Evolution of Algol family • Recursive functions and parameter passing � Lambda calculus • Evolution of types and data structuring � Denotational semantics � ML: Combination of Lisp and Algol-like features � Functional vs. Imperative Programming • Expression-oriented • Is implicit parallelism a good idea? • Higher-order functions • Is implicit anything a good idea? • Garbage collection • Abstract data types • Module system • Exceptions Types and Type Checking Type inference algorithm � Types are important in modern languages � Example • Program organization and documentation - fun f(x) = 2+x; Graph for λ x. ((plus 2) x) • Prevent program errors > val it = fn : int → int t → int = int → int • Provide important information to compiler λ � How does this work? � Type inference int (t = int) @ Assign types to leaves • Determine best type for an expression, based on known information about symbols in the expression int → int @ Propagate to internal x : t � Polymorphism nodes and generate + 2 : int • Single algorithm (function) can have many types constraints int → int → int � Overloading real → real → real Solve by substitution • Symbol with multiple meanings, resolved at compile time 3

  4. Block structure and storage mgmt Summary of scope issues � Block-structured languages and stack storage � Block-structured lang uses stack of activ records • Activation records contain parameters, local vars, … � In-line Blocks • Also pointers to enclosing scope • activation records � Several different parameter passing mechanisms • storage for local, global variables � First-order functions � Tail calls may be optimized • parameter passing � Function parameters/results require closures • tail recursion and iteration • Closure environment pointer used on function call � Higher-order functions • Stack deallocation may fail if function returned from call • deviations from stack discipline • Closures not needed if functions not in nested blocks • language expressiveness => implementation complexity Control Modularity and Data Abstraction � Structured Programming � Step-wise refinement and modularity • Go to considered harmful • History of software design � Exceptions � Language support for information hiding • “structured” jumps that may return a value • Abstract data types • dynamic scoping of exception handler • Datatype induction � Continuations • Packages and modules � Generic abstractions • Function representing the rest of the program • Generalized form of tail recursion • Datatypes and modules with type parameters • Design of STL Concepts in OO programming Simula 67 � Four main language ideas � First object-oriented language • Encapsulation � Designed for simulation • Dynamic lookup • Later recognized as general-purpose prog language • Subtyping � Extension of Algol 60 • Inheritance � Standardized as Simula (no “67”) in 1977 � Why OOP ? � Inspiration to many later designers • Extensible abstractions; separate interface from impl • Smalltalk � Compare oo to conventional (non-oo) lang • C++ • Can represent encapsulation and dynamic lookup • ... • Need inheritance and subtyping as basic constructs 4

Recommend


More recommend