MID-QUARTER REVIEW

From Typing
-----------
  - Compilers as an engineering discipline
     + Engineering creates things that are of use to people
     + Cost/benefit analysis is inherent
        - ``perfect'' artifact has infinite cost
        - many variables/dimensions to optimize
     + ``Failures'' drive engineering process: actual, predicted, imagined
     + Failure is inherent in ``improvement''
     + Creative step is seeing how existing technology can be applied
     + Risks and responsibilities

  - Modularity
     + Hide changeable details within a module to localize future change
     + Common detail to hide is data structure: ADT's and classes
     + Modularity is easier said than done; requires diligence, experience
     + Example: Symbol table entries, variables, types
        - all entries of a symbol table have two things in common: name, scope
        - otherwise might be a type, a variable, function, etc.
        - one possibility is to put all the fields (members) for these into
          the symbol table entries.
        - but then changing type stuff means you're digging around variable
          stuff; changing lookup method requires digging around variables, etc.
        - symbol table entry is an association between a name and value, but
          what type of value is irrelevant, so keep value separate (point to it)
        - also, entities don't always have names (anonymous types), and
          names don't always have entities
        - can get the best of both worlds with OO (sort of)
           + basic STO class is a name and no value
           + subclasses get values of all different sorts
           + thus the special cases are all separated out, but all
             share common STO root

  - Notion of type
     + Set of values, operations on those values, rules for use
     + Full notion of type includes behavior of those operations
     + ``Static'' notion of type only articulates required input-output
       rules of operations, not operation's (run-time) behavior.
     + Types are organized in a hierarchy (e.g., subrange < int < real)
        - coercion: automatically make lower value into higher value
        - overloading: reuse names of operations
        - assignability: just coercion, except when rules not consistent
     + Need a representation of type that permits:
        - equality comparison (structure vs. name)
        - retrieving types of subcomponents: element type, parameter, field
           + parameters accessed by position
           + fields accessed by name: like ST
        - subtyping, etc.

  - Syntax-Directed Development: match structure of solution to structure of problem
     1. Specification is written in terms of language syntax/features
     2. Code is incrementally developed feature by feature
     3. Checking (and later, code gen) is driven off of parser's syntax-directed
        actions
     4. Tests are written on a per-feature basis
     + Alignment of these four:
        - leverages domain theory: syntax-directed compilation
        - divides problem into pieces, making intellectually tractable
        - incrementalizes development, reducing schedule risks
        - simplifies tracking of progress among all four

  - Attribute management
     + Two sources of attributes (values) during parsing
        - synthesized: values computed from children (e.g., :e1, :e2, etc.);
          values are propagated upward (via assignment to RESULT during parsing.
        - inherited: values computed from ancestors; values are passed
          downwards during parsing.
     + Main issue is that information at different places in the parse
       need to be brought together to be combined or compared for consistency.
        - Propagate ``loop'' to ``exit''; propagate IDList to TypeDecl.
        - Sometimes have choice of bringing one to other, or vice versa
        - Can also reorganize grammar to change I/S relationship; icky
     + LALR parsers don't support I.A. because there is no parent to inherit
       from, due to bottom-up nature: parent is LHS, which is created by
       reduction rule.
     + Easy to simulate, though, because most constructs have a tell-tale
       lead-off tag such as FUNCTION, LOOP, etc., and nested properties of
       grammar are easily modelled with a stack
        - After seeing tell-tale construct, push attribute on a user-defined
          attribute stack especially designed for that attribute
        - While in the construct, can check attribute via top of stack
        - When exit construct, pop off attribute

From Runtime Systems
--------------------
 - Compilation as model matching
    + We have two languages (machines), a program in language
    + Want to create program in other language
    + Languages are often radically different, and at different levels
    + Figure out how target language constructs can mimic source constructs
       - ask questions about source lang to identify its complexities
          + recursion, first class functions, backtracking, etc.
       - stack and call frames for procedure call
       - base + offset for variables names, etc.
       - load-load-compute-store for memory/register mapping
       - as idioms, these represent a higher-level version of target, sometimes
         called ``compiler writer's virtual machine''

 - Runtime systems
    + Advanced features available to compiler or programmer to simplify
       - stack
       - call sequence
       - memory management (malloc, free, garbage collection)
    + Help bridge gap between source and target language
       - link in library code
       - added to program with emit