Page Numbers: Yes X: 306 Y: 1.0" First Page: 1
Margins: Top: 1.0" Bottom: 1.3"
Heading:

LECTURE NOTES #2 LISP: LANGUAGE AND LITERATURE April 17, 1984
————————————————————————————————————————————

Lecture Notes #2 — XXX

Filed as:[phylum]<3-lisp>course>notes>Lecture-02.notes
User.cm:[phylum]<BrianSmith>system>user.classic
Last edited:April 17, 1984 10:13 AM

————————————————————————————————————————————

Introduction

1.Last lecture philosophical overview; over the last weekend nitty-gritty details of machines.

—Idea is to have class be at a more theoretical level than sections and programming time.

—Today, start somewhat practically, since people probably won’t have finished reading the primer, problem set, etc.

—Move towards more theoretical issues.

2.Goals today are:

—Distinguish between programs, procedures, functions, and processes.

—People won’t tell you where they live.

—The 3-LISP Simplification Procedure: zero-order model

—Conversational Context ("static" scoping)

—Higher order functions: modularity, parameterization, and abstraction

————————————————————————————————————————————

Outline:

1.Remind of situation: conversation with 3-LISP processor.

—Agency, anima — ultimately irreducible.

—Declarative reading not sufficient; saw that last week.

—Today will shift to a procedural reading, albeit still an extensional one

—Cf. structure of 3-LISP primer.

—Primary subject matter (as well as numbers etc.) is with behaviour it can manifest, programs it can run, etc.

3.The Processor normalises what we type in; pretty minimal kind of conversation partner, but can make it do a lot of work.

—Normalisation is a kind of simplification

—Draw standard picture.

—But reason it can get a lot done is there are commands, effectively, that change the state of the 3-LISP processor (mostly, at the moment, by increasing its vocabulary).

—Won’t say how these changes are effected, at the moment.

4.On the definition of functions:

—Not only talk about functions, but encode in the way we talk about them a procedure for it to follow in "evaluating" the function.

—I.e., not only meaning, but intensional structure is used as specifying a procedure.

—Conversation is in some sense overloaded.

—This is why we cannot have "the x such that ... ", as mentioned last time.

—Leads towards an imperative style of language (cf. BASIC, assembly languages, etc.)

—Seductive, at first (turtle examples! that’s one reason people will like them); turns out not to be ideal in the long run.

—Want to separate out what you are talking about, and the particular algorithm used to compute it (motherhood, these days).

—Wonderful, when the machine itself can somehow figure that out. Note that it does so for simple things (we don’t tell it how to add numbers) already; can imagine it being much cleverer. Compilers can play with it, change algorithms around, etc.

—On the other hand, you sometimes want, quite explicitly, the ability to tell the machine what to do (i.e., how to reason), as well as talking about some subject domain.

—Providing this ability, in ways that don’t trip over the inscrutability of basic-like languages, isn’t well understood.

—Distinction is absolutely important to get clear.

—Example Ex-02-02:

—In other words, some primitive constructs have procedural consequence: FORWARD 100 in the problem set, for example. But also, the grammatical structure of programs has procedural consequence, because of this overloading.

—Will look at it in some detail.

—Tremendous amount of stuff going on:

—Relationship, for example, between the order of the notational presentation of the program (which is a temporal order, if you take the conversational view), and the temporal order of the process that results.

—Not one-to-one; cf the basic program, and the recursion in the other ones.

5.3-LISP Processing

—Ok, given all of this, see what a program actually does.

—Note: still talking procedurally, but extensionally; will still characterize the process in terms of the designation of the structures it manipulates.