LISP: Language and Literature

Filed as:[phylum]<3-lisp>course>notes>LLL-Outline.bravo
Last edited:April 4, 1984 12:09 AM

Original Sections:

0.Introduction;

1.Procedural and data abstraction;

2.Objects, modularity, state, and encapsulation;

3.Input/output, notation, and communication protocols;

4.Meta-linguistic abstraction, and problems of intensional grain;

5.Architecture, implementation, and abstract machines;

6.Introspection, self-reference, meta-circular interpreters, and reflection.

Themes:

1.Procedural and declarative notions of semantics;

2.Interpretation, compilation, and other models of processing;

3.Implicit vs. explicit representation of information;

4.Contextual relativity, scoping mechanisms, and locality;

5.Varieties of language: internal, external, theoretic;

6.Syntax and abstract structure: funcitonalism and representationalism.

0.Introduction

—Three goals:

a.Convey computational intuitions, so that people have their own original authentic, sense of computation, rather than a derivative one.

b.Provide an explicit theoretical language in terms of which to understand the understanding conveyed in the first. I.e., understand computation both tacitly and computationally, in a coordinated way.

c.Have that theoretical language be continuous with, and consonant with, the theoretical language they would be disposed to use in describing the use of language by any finite agent.

—XXX:

—Computer science primarily studies processes, and secondarily the languages used to describe and interact with them. Linguistic primarily studies languages, and only secondarily the processes that underlie them. In this course we will focus on a pretty balanced combination of the two.

—There will be lots of different languages. Part of the point will be to keep them clear and distinct, and to describe the relationships between them. For that matter, there will be lots of different processes; we will try to be clear about them, too. The real subject will be at the juncture between them -- where language and process interact.

—LISP is neither a language nor a process, but an amalgam.

1.Procedural and Data Abstraction:

—Declartvie reading --- an extensional viewpoint

—Functions, Numbers, TRuth-values, Sequences, etc. — mathematical ontology.

—1sty and Higher-order functions

—F’, and F and Y.

—PRoceudres: flfunctions in intension. Algorithms (this is a minor entry — worth noting).

—Basic diagram of F, Y, and the modelling stuff (MW), etc.

2.Objects, Modularity, and State

—no Y defined over "object-level" (data) structures.

—identity conditions

—typing, type checkers, etc.; abstract types; strong typing; hierarchies; type-directed programming, leading towards message-passing "object-oriented" sytsems.

—representatiopnal vs. functional accounts, dtat tsructurtes, setc.

—enacapsulation.

—Impacf of representation on calculation (bit maps, run-length encodings, etc.)

—Implicit vs. explicit represnetations of information.

—Statements, and the lack thereof: assertional force.

—Side effeffects; modularity, mutable objects;

—Programs are about data structurtes -- the meta-structural viewpoint.

3.Communication, etc. ....

—Q, strings,etc.

—parsing, tranduction, etcv. (with consequent complexity considreations)

—"backquote", explicit representation of structure vs. embodiment of it.

—lexical macros, string quotation, etc.

—READ and PRINT

—Limits of language to express wqhat’s in the mind (use closures as an example?)

—Communication between independent processes.

4.Meta-structural Abstraction

—Structural macros

—lambda abstraction and closures

—dealing extensionally with intensional content (↑)

—Comments/type declaraionts, etc.

5.Architectue and Implementation

—Constraint machines

—Concurrent processes

—Objected oreitned languages

—Unification

—Modelling and simluation vs. analysis

—Implementaiton of LISP in a register achine (pointers, garbage collection, etc.)

—F across implementation boundaries.

—Realisation

6.Introspection and Reflection

—Meta-circular processors

—debuggers, etc.,

—Reflection

—Implicit vs. explicit, revisted. (trading between them.)

--- what about:

n.Models of Processing

—Models of processing;’ process vs. processor.

—Recursions

—Tail recursion etc.; iteration.

—Scoping protocols; immediate vs. remote, lexical/static vs. dynamic, etc.

—Context in general

—Process vs. program structure (questions of modularity)

—Complexity considerations.

m.Theory:

—Absorption

—Mathemtaical Models

—Formal semantics.

o.Specification and Correctness:

—Bring up the moral issues

Outline from working at Home:

0. Introduction

—Standard 3 goals

—Because of third, collaborative enterprise

—Violence to traditional theoretic language; make no one happy

—Will make terminology tricky; try to admit when a new term is being introduced, and also provide running commentary from a variety of field’s perspectives.

—In particular, won’t make computer scientists any happier than anyone else. Justice is being done to practice, not to standard reconstruction.

—Also, very notion of language will not necessarily be familiar: whether we mean a set of expressions, or those plus an interpretaion, or those plus processes that use them, etc. To borrow a technique from B&P, note words that you might think you knew what meant; caveat emptor:

—Language

—Extension

—Value and Evaluation

—Interpretation These are words from the theory of language, not from language itself; no a priori reason to suppose they will suffice for this reconstruction.

—Various languages, various processes (from old outline).

—Summarize whole outline (BIG task)

—Start in: problem: what to talk about? All it knows about are

—Its internal structures;

—Mathematical abstractions;

—Notation (strings) and language; To "tell it" about anything else (represent any other kind of information) requires representation, which involves us in too much complexity (because its too important). Problem with 1st is you don’t know anything about it; with third, that it involves us with both using and mentioning language, with the concomitant tendency to slip into use/mention confusion (can and will keep it straight, but makes life complex). So start (with apologies) with simple mathematical examples. Will use a certain number of "notational" examples in due course.

—Other introductory points to be made:

—Use of mathematics to classify things; terrible for semantic intuitions.

—Will end up with: a framework in which:

—to talk about languages and processes, and the relationship between them (i.e., behaviour and aboutness);

—to relate various levels of language: extensional, intensional, syntactic, etc. (in arbitrary combination: an expression A whose extension is the intension of another expression B, etc.).

—Fundamental claim that computation is about things

—Language/process distinctions (see old outline)

—Abstraction, modularity, complexity.

—Intensional aspects of symbolic or linguistic structures (word intensional is theory relative, but we will use it going in) is crucial, both computationally and in terms of mind (this is one of the reasons they are potentially related).

—Standard semantical notions are simply not complex enough (interpretation, designation, etc.).

—Programs: theoretic descriptions of processes, or languages that processes use to communicate. Ambiguity: we will characterise both.

—Stuff that we will deal with, primarily, is ABOVE level of individual syntactic constructs; rather, will be concerned with the way in which they are put together. This is why the "literature" orientation, rather than just details of the linguistic constructs themselves. Overall goal is (to quote A&S) is to learn how "to control the intellectual complexity of large software systems".

—Programs are meant to be read by people; i.e., they serve a communication role as well as generating processes inside the machine.

—Be a platonist about mathematics. Don’t really care about mathematics; point is that we will be using mathematics to classify things; analogy will go through only if you assume that mathematical abstractions trancend their embodiment in language or machine.

—Will not resist mathematical theorizing about what we do, but will put it of until we have satisfied both of the first two goals; want people to have the intutions before we try to formalize them.

—Blunt: things will get more interesting as course goes on. Have to lay some groundwork. That is why the summary should be given in the first lecture.

1. Simple Procedural and Data Abstraction

—Really, before can do anything, we need to be able to deal fluently with "procedures", simple and complex.

—Start with a simple language about mathematical objects: numbers, functions, sequences, and truth-values. From a purely formal (syntacticAL) point of view, three things:

—Primitive expressions

—Means of combination

—Means of abstraction

—Semantically, have to say what all of this "means". Use "SIGNIFICANCE" for the most general semantic notion. Thus: ask what the significance is for each of the syntactic forms.

—Designate numbers with numeral expressions, truth-values with boolean constant expressions, sequences with square-bracketed expressions. Functions with lambda expressions (usual fashion). Also constant (pre-interpreted) function constants: +, *, MAX, etc. Finally, a conditional operator: IF.

—Give a few examples, embedded, etc.

—Crucial fact is that this is an entirely static situation, so far: no computation. Suppose you type the expression "(+ 2 3)" to the computer; will get back the expression "5". Normally said that computer has "evaluated" the expression; I will argue that this either doesn’t mean anything or else is false. But is is crucial to realize that something has happened (it took up time, for example -- we could even measure how much), whereas nothing we have said so far about what this language meant said anything whatsoever about BEHAVIOUR.

—MASSIVE PUN: by simplifying the expression (or something analogous to it), the computer can do something that can be CLASSIFIED as following the procedure that we would take the program as INTENSIONALLY representing.

—Note that it doesn’t ACTUALLY follow the procedure, because to do that would require trafficking in numbers, which it can’t (on our platonic assumption).

—Note also that this is why the language is restricted to constructive notions: don’t have formal analogs of "THE x such that ... ", because no procedure is intensionally associated with it, so pun can’t hold. Once we clear up the pun, we may allow non-constructive language back into the game.

—Here is "behaviour" and "aboutness" getting mixed, again.

—Note that when we get to the point of "saying" to the computer: "John walked to the store by way of the cathedral", what we say will have an intensional reading, but it doesn’t correspond to the intension of anything that the computer will be expected to do by way of response or comprehension. Something special about the program we have used so far (hint: has to do with the fact that it is a PROGRAM).

—Introduce full diagram? Show why mathematical examples are SO misleading.

—Resolve: keep program, and process, and designation, distinct. Also, all of these from the mathematical structures used to classify them.

2. Models of Processing

—So, we started thinking DECLARATIVELY, but saw that this won’t suffice. Will start thinking PROCEDURALLY, but still by and large EXTENSIONALLY -- i.e.,in terms of the mathematical objects we use to classify the machine state.

—Introduce SET, DEFINE, etc.

—Introduce SUBSTITUTION model of processing. Leads to the notion of a REDUCTION machine: one that simplifies expressions to simpler cases.

—PROCESS vs. PROCESSOR: serial model of computation. Expressions inside the machine. I.e., way it works is for program to be put inside the machine, as part of a dual component process, and then have it executed.

—There are other ways this could happen; this is only 1 possibility.

—Note that we have adopted an intensional reading: program QUA EXPRESSION is playing a causal role in the process that is engendered.

—Given all this, proceed with a variety of algorithms over numbers etc., so as to get our procedural skills up to snuff.

—Recursion, iteration, higher-order procedures, all that good stuff.

—Class: emphasis on modularity, generality, abstraction.

—Introduce objectified arguments; general notational abbreviation ("un- curried" arguments).

—Problem sets:

—Problems:

—Iterative approximations for square roots;

—Filling algorithm for text justification;

—Turtle Graphics

—FP: insert, multi-argument +, map, etc.

—Extra credit: Product/Sum riddle.

—Small examples:

—Define IF* to use keywords THEN and ELSE; then just another ordinary one; explain why doesn’t work.

—Iterative constructs: DO, ITERATE, etc.; design a simpler one?

—Points to get across:

—Fence-post errors

—Internal naming abstractions (LET)

—Internal procedures (LETREC)

—Flexibility of procedure design; hack something up.

—Recognition that things we use (IF, DO, LETREC) cannot be defined using the machinery we have presented so far.

3. Simple Data Abstraction