COP 4020 Lecture -*- Outline -*-

* Concepts (intro to Ch 6, 6.1-6.2)

    Based on Peter van Roy and Seif Haridi's book,
    "Concepts, Techniques, and Models of Computer Programming"
    (MIT Press, 2004),
    where all references that are not otherwise attributed are found.

** declarative vs. imperative

   Q: What's the meaning of "declarative programming"?
   should be about description,
   a matter of degree:
          Fortran vs. Assembler: Fortran is more declarative

   traditionally:
      declarative = stateless
      imperative = stateful (has state and assignment)

   declarative readings:

    logic programs can be read as "logic + control" (Kowalski)
    functional program can be read as a set of mathematical definitions

    but these often aren't very realistic
     (cut, tail-recursion, etc. interfere with the straightforward reading)

** state
------------------------------------------
            STATE

def: state is a time-indexed sequence
     of values

Implicit (declarative) state:

  - accumulator arguments
  - doesn't live apart from calls

Explict state:

  - lives apart from calls' arguments
  - hidden from callers

        CELLS FOR EXPLICIT STATE

Operations

  NewCell : <fun {$ T}: <Cell T>>
  @ : <fun {$ <Cell T>}: T>
  := : <fun {$ <Cell T> T}: T>

------------------------------------------

    Q: Why is hiding the state from callers important?
    Information hiding

    Q: Can explicit state be programmed in the declarative model?
    No

    Importance:
       removes limits of declarative model
       data abstractions can be much more modular
       can be used sequentially

** state and system building (6.2)
*** abstraction

------------------------------------------
          PRINCIPLE OF ABSTRACTION

All systems have 2 parts:

   - specification
   - implementation

Layers:

   - Specification is often simpler
   - Build system in layers
------------------------------------------

     Q: What point of view is used to write specifications?
     Client's or outside view

     Q: What's meant by building a system in layers?

     Q: Why is that helpful?
     Spec is often simpler,
     Don't have to understand everything at once

*** systems that grow + system properties (6.2.1)

------------------------------------------
     HOW TO SUPPORT ABSTRACTION

Needs:

  - growth/change
      ==> accumulate knowledge

  - abstraction/modularity
      ==> protect/hide knowledge

  - compositionality (combining parts)
      ==> encapsulation of knowledge
          + control of dependencies

  - instantiation (parameterization)
      ==> abstract/parameterize knowledge
     
------------------------------------------

   Encapsulation is key

   Q: How did we get encapsulated state
      from the message passing model? 
        state can be kept in internal arguments of port object
        requires concurrency (Why?)

     Here we get state without concurrency

   Q: Why not make all state global?
   Too hard to reason about.

   Reasoning:
      - safety properties (nothing bad happens): invariants
      - liveness properties (something good happens): progress metric

   They advocate building systems with only a few stateful components

*** component-based programming (6.2.2) + OOP (6.2.3)

------------------------------------------
          COMPONENTS

- procedures
- functors (compilation units)
- concurrent actors
- objects
------------------------------------------

        In OOP inheritance (incremental extension with recursive binding)
        is also important