DOCSLIB.ORG

Handout 10: Procedures and Objects the Basic Imperative Language (See Handout 11) Has Only Commands, Variables and Expressions

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Handout 10: Procedures and Objects the Basic Imperative Language (See Handout 11) Has Only Commands, Variables and Expressions 06-02552 Princ. of Progr. Languages (and “Extended”) The University of Birmingham Spring Semester 2019-20 School of Computer Science c Uday Reddy2019-20 Handout 10: Procedures and objects The basic imperative language (see Handout 11) has only commands, variables and expressions. In this handout, we examine adding procedures and objects (actually classes). 1 Algol-like languages Procedures can be added to the basic imperative language using the typed lambda calculus. This was in fact done in the first systematically designed programming language, Algol 60, defined by an international committee of computer scientists.1 John Reynolds,2 in 1981, proposed a systematic redesign of Algol based on typed lambda calculus and called it Idealized Algol. We follow his approach. 1. Typed lambda calculus Recall that the types of a typed lambda calculus are given by the syntax: T ::= b j T1 ! T2 where b ranges over basic types. For a functional programming language, we choose basic types such as Int, Bool etc. For an imperative programming language, we can choose basic types that represent state-based computations. 2. Lambda calculus for imperative programs To obtain a typed imperative programming language, we pick basic types to be those representing imperative programming concepts (cf. Handout 11). These are: • Mutable variables, also called references, representing storage locations. • Expressions that read the state of variables and return a value (“state readers”) • Commands that alter the state of variables (“state transformers”). Variables, expressions and commands are not treated as types in typical imperative programming languages. Rather, they are designated as separate syntactic categories. However, to obtain the full power of typed lambda calculus, it is useful to regard them as types. The basic data types such as int, bool, and char or not regarded as types of the lambda calculus. This is because there are no terms in imperative programming languages that directly denote data values (except constants). Rather, terms denote either mutable variables or expressions, each of which might deal with values of particular data types. Let δ stand for types such as int, bool, . Then the basic types of the lambda calculus for imperative programs are: • var[δ], also written as ref[δ], for variables that store δ-typed data values. • exp[δ], for expressions that return δ-typed data values. • comm, for commands. In summary, the types of our lambda calculus for imperative programs is as follows: T ::= var[δ] j exp[δ] j comm j T1 ! T2 3. Terminology: variables, references and identifiers. Note that the term “variable” in imperative programming refers to storage locations whose values can be modified. In contrast, lambda calculus as well as standard mathematics use the term “variable” for a completely different concept, viz., symbols used to stand for values. 1It is doubtful if the committee members knew lambda calculus fully, but they reinvented some of its ideas for themselves. Thus Algol had only part of lambda calculus, not the full calculus. Peter Landin showed the correspondence between the two procedure mechanisms a few years later. See Landin, Peter. A correspondence between ALGOL 60 and Church’s Lambda-notations: Part II, Communications of the ACM, March 1965. 2Reynolds, John. The essence of Algol, in Algorithmic Languages, North-Holland, 1981. 1 To avoid conflict between the two uses, Algol 68 introduced the term “reference” for mutable variables in the sense of imperative programming. The terminology did not catch on within the imperative language culture (except in isolated usages like “call by reference”). However, it became standard in functional programming culture. So, we use both the terms “variable” and “reference” for referring to this concept. Algol 60 used the term “identifier” to what we call variable in mathematics and the lambda calculus. So an “identifier” is a symbol, used for formal parameters for functions and for naming various things, like functions, types, classes etc. For example, in the term λx. x + y of type exp[int] ! exp[int], the symbol x is a bound identifier and y is a free identifier. 4. Constants for imperative programs All the primitive operations of the imperative programs are modelled as constants in our typed lambda calculus. We group them into four classes, for ease of exposition: • Primitive operations for expressions. All the constants and primitive operations needed for data values are expressed as constants that act on exp types. Some examples are: 0, 1, 2, ...:: exp[int] true, false :: exp[bool] +, -, ... :: exp[int] ! exp[int] ! exp[int] =, <, ... :: exp[int] ! exp[int] ! exp[bool] &&, || :: exp[bool] ! exp[bool] ! exp[bool] not :: exp[bool] ! exp[bool] The only thing surprising about these types is that they involve the exp type constructor. We need the exp type constructor because, in general, the arguments for operations such as + are “expressions” which can read the state of variables. The result of such an application, e.g., x + y, is again an expression that is state-dependent. • Primitive operations that deal with commands. These are as follows: skip :: comm (;) :: comm ! comm ! comm if :: exp[bool] ! comm ! comm ! comm Note that (; ) is an infix operator. For if, we will use the syntactic sugar: if B then C1 else C2 if BC1 C2 • Primitive operations that deal with variables. These are as follows: read :: var[δ] ! exp[δ] (:=) :: var[δ] ! exp[δ] ! comm The assignment operator (:=) is an infix operator. Note that the type implies that, if V is a variable and E an expression then V := E is a command. Its effect is to evaluate E and assign its value to V . The read operation is normally left implicit in typical Algol-like languages. But it says that, if V is a variable, then read V is an expression. Its effect is to read the value of V and return it. Leaving the read operation implicit means that, whenever a variable is used in a position where an expression is expected, we automatically insert a read operator. For example, we write x := x + 1 where the variable x on the right hand side is used where an expression is needed. So, we understand it as: x := (read x) + 1 This convention is only used in what we traditionally call “imperative” languages. Functional languages like ML and Haskell have the read operation explicit. • Finally, we have an operation for local variable declarations: local[δ] :: (var[δ] ! comm) ! comm The effect of local[δ] B is to create a new local variable for δ-typed values, say V , and then execute B(V ). After B(V ) finishes, the local variable is deallocated. 2 Since this form looks a little heavy in normal usage: local[int](λx. C) we use the simpler notation: flocal[int] x; Cg and understand it to have the same effect. In summary, all the behaviour of imperative programs can be modelled using a few primitive functions in terms of the basic types var[δ], exp[δ] and comm. 5. Procedures. The procedures of Algol-like languages are mapped directly into the functions of lambda calculus. For example, the Algol 60 procedure declaration: procedure swap(var[int] x, var[int] y) f local[int] t; t := x; x := y; y := t g is thought of as the definition of a function swap: let swap = λx. λy. flocal[int] λt. t := read x; x := read y; y := read t g The type of swap is: swap : var[int] ! var[int] ! comm In general, a procedure is always a function that has comm is its codomain type.3 A function that has an exp[δ] type as its codomain type is thought of as a “function procedure” or sometimes just called a “function”. (But this is misleading because all procedures are functions.) 6. Semantics of procedure call. Prior to Algol 60, the meaning of a procedure such as swap was understood operationally, in terms of machine instructions that would be executed. That story might run as follows: 1. Push references to the variables i and j on the system stack. 2. Push the program counter on the stack, and jump to the code of swap. 3. When the code of swap finishes, pop the arguments i and j as well as the saved program counter from the system stack, and jump back to the saved program counter position. The definition of Algol 60 put paid to such operational descriptions. The semantics of a procedure call, as given in the Algol 60 Report, is to simply copy the body of the procedure to where the procedure call appears, and replace the formal parameters by the arguments, like so: . swap i j; fint t; =) t := read i; i := read j; j := read tg . This semantics came to be known as the Algol copy rule. We might also call it procedure unfolding. Note that the copy rule is precisely the β-equivalence reduction rule of the lambda calculus. 3It is not useful to think of this as a function “returning” a command. The idea of “returning” results only makes sense in purely functional languages. Here it is better to think of swap as “mapping” two variables x and y into a command. 3 2 Objects and classes Whereas in functional programming, data abstraction is achieved by abstracting over a type, in imperative programming it is more common to abstract over storage. The resulting abstractions are called objects. The behaviour of objects is defined via classes. Historically, objects and classes were introduced in the language Simula 67.4 They were popularised by the language C++ in the 1980s and widely adopted since then. An object encapsulates some amount of storage, represented by mutable variables or other objects, and provides operations that can be used by clients.
Load more

Recommended publications
  • A Universal Modular ACTOR Formalism for Artificial
    Artificial Intelligence A Universal Modular ACTOR Formalism for Artificial Intelligence Carl Hewitt Peter Bishop Richard Steiger Abstract This paper proposes a modular ACTOR architecture and definitional method for artificial intelligence that is conceptually based on a single kind of object: actors [or, if you will, virtual processors, activation frames, or streams]. The formalism makes no presuppositions about the representation of primitive data structures and control structures. Such structures can be programmed, micro-coded, or hard wired 1n a uniform modular fashion. In fact it is impossible to determine whether a given object is "really" represented as a list, a vector, a hash table, a function, or a process. The architecture will efficiently run the coming generation of PLANNER-like artificial intelligence languages including those requiring a high degree of parallelism. The efficiency is gained without loss of programming generality because it only makes certain actors more efficient; it does not change their behavioral characteristics. The architecture is general with respect to control structure and does not have or need goto, interrupt, or semaphore primitives. The formalism achieves the goals that the disallowed constructs are intended to achieve by other more structured methods. PLANNER Progress "Programs should not only work, but they should appear to work as well." PDP-1X Dogma The PLANNER project is continuing research in natural and effective means for embedding knowledge in procedures. In the course of this work we have succeeded in unifying the formalism around one fundamental concept: the ACTOR. Intuitively, an ACTOR is an active agent which plays a role on cue according to a script" we" use the ACTOR metaphor to emphasize the inseparability of control and data flow in our model.
    [Show full text]
  • Fiendish Designs
    Fiendish Designs A Software Engineering Odyssey © Tim Denvir 2011 1 Preface These are notes, incomplete but extensive, for a book which I hope will give a personal view of the first forty years or so of Software Engineering. Whether the book will ever see the light of day, I am not sure. These notes have come, I realise, to be a memoir of my working life in SE. I want to capture not only the evolution of the technical discipline which is software engineering, but also the climate of social practice in the industry, which has changed hugely over time. To what extent, if at all, others will find this interesting, I have very little idea. I mention other, real people by name here and there. If anyone prefers me not to refer to them, or wishes to offer corrections on any item, they can email me (see Contact on Home Page). Introduction Everybody today encounters computers. There are computers inside petrol pumps, in cash tills, behind the dashboard instruments in modern cars, and in libraries, doctors’ surgeries and beside the dentist’s chair. A large proportion of people have personal computers in their homes and may use them at work, without having to be specialists in computing. Most people have at least some idea that computers contain software, lists of instructions which drive the computer and enable it to perform different tasks. The term “software engineering” wasn’t coined until 1968, at a NATO-funded conference, but the activity that it stands for had been carried out for at least ten years before that.
    [Show full text]
  • Actor Model of Computation
    Published in ArXiv http://arxiv.org/abs/1008.1459 Actor Model of Computation Carl Hewitt http://carlhewitt.info This paper is dedicated to Alonzo Church and Dana Scott. The Actor model is a mathematical theory that treats “Actors” as the universal primitives of concurrent digital computation. The model has been used both as a framework for a theoretical understanding of concurrency, and as the theoretical basis for several practical implementations of concurrent systems. Unlike previous models of computation, the Actor model was inspired by physical laws. It was also influenced by the programming languages Lisp, Simula 67 and Smalltalk-72, as well as ideas for Petri Nets, capability-based systems and packet switching. The advent of massive concurrency through client- cloud computing and many-core computer architectures has galvanized interest in the Actor model. An Actor is a computational entity that, in response to a message it receives, can concurrently: send a finite number of messages to other Actors; create a finite number of new Actors; designate the behavior to be used for the next message it receives. There is no assumed order to the above actions and they could be carried out concurrently. In addition two messages sent concurrently can arrive in either order. Decoupling the sender from communications sent was a fundamental advance of the Actor model enabling asynchronous communication and control structures as patterns of passing messages. November 7, 2010 Page 1 of 25 Contents Introduction ............................................................ 3 Fundamental concepts ............................................ 3 Illustrations ............................................................ 3 Modularity thru Direct communication and asynchrony ............................................................. 3 Indeterminacy and Quasi-commutativity ............... 4 Locality and Security ............................................
    [Show full text]
  • The Discoveries of Continuations
    LISP AND SYMBOLIC COMPUTATION: An InternationM JournM, 6, 233-248, 1993 @ 1993 Kluwer Academic Publishers - Manufactured in The Nett~eriands The Discoveries of Continuations JOHN C. REYNOLDS ( [email protected] ) School of Computer Science Carnegie Mellon University Pittsburgh, PA 15213-3890 Keywords: Semantics, Continuation, Continuation-Passing Style Abstract. We give a brief account of the discoveries of continuations and related con- cepts by A. van Vv'ijngaarden, A. W. Mazurkiewicz, F. L. Morris, C. P. Wadsworth. J. H. Morris, M. J. Fischer, and S. K. Abdali. In the early history of continuations, basic concepts were independently discovered an extraordinary number of times. This was due less to poor communication among computer scientists than to the rich variety of set- tings in which continuations were found useful: They underlie a method of program transformation (into continuation-passing style), a style of def- initionM interpreter (defining one language by an interpreter written in another language), and a style of denotational semantics (in the sense of Scott and Strachey). In each of these settings, by representing "the mean- ing of the rest of the program" as a function or procedure, continnations provide an elegant description of a variety of language constructs, including call by value and goto statements. 1. The Background In the early 1960%, the appearance of Algol 60 [32, 33] inspired a fi~rment of research on the implementation and formal definition of programming languages. Several aspects of this research were critical precursors of the discovery of continuations. The ability in Algol 60 to jump out of blocks, or even procedure bod- ies, forced implementors to realize that the representation of a label must include a reference to an environment.
    [Show full text]
  • PRME Conference Programme V1.Indd 1 21/06/2018 23:49 Contents
    The School of Business and Management, Queen Mary University of London is delighted to be hosting the 5th UN PRME UK and Ireland Conference 5th UK and Ireland PRME Conference Inclusive Responsible Management Education in an Era of Precarity 25-27 June 2018 PRME is working to help achieve UN sustainable development goals QM18-0002 - UN PRME Conference Programme v1.indd 1 21/06/2018 23:49 Contents Welcome to Queen Mary, University of London ...........................3 Conference Information .....................................................................4 Conference Dinners ...........................................................................4 Conference Theme .............................................................................6 Conference Schedule ........................................................................7 Speaker Biographies ....................................................................... 12 Paper Abstracts................................................................................ 16 2 www.busman.qmul.ac.uk QM18-0002 - UN PRME Conference Programme v1.indd 2 21/06/2018 23:49 Welcome to Queen Mary, University of London! Welcome to 5th UN PRME UK and Ireland Conference. Our Theme this year ‘Leaving no one behind’ - Inclusive Responsible Management Education in an Era of Precarity’ is resonant with the ethos and spirit of the School of Business and Management at Queen Mary. We are indeed honoured to be playing host to this prestigious event as the conference highlights our intrinsic commitment
    [Show full text]
  • A Rational Deconstruction of Landin's J Operator
    BRICS RS-06-4 Danvy & Millikin: A Rational Deconstruction of Landin’s J Operator BRICS Basic Research in Computer Science A Rational Deconstruction of Landin’s J Operator Olivier Danvy Kevin Millikin BRICS Report Series RS-06-4 ISSN 0909-0878 February 2006 Copyright c 2006, Olivier Danvy & Kevin Millikin. BRICS, Department of Computer Science University of Aarhus. All rights reserved. Reproduction of all or part of this work is permitted for educational or research use on condition that this copyright notice is included in any copy. See back inner page for a list of recent BRICS Report Series publications. Copies may be obtained by contacting: BRICS Department of Computer Science University of Aarhus IT-parken, Aabogade 34 DK–8200 Aarhus N Denmark Telephone: +45 8942 9300 Telefax: +45 8942 5601 Internet: [email protected] BRICS publications are in general accessible through the World Wide Web and anonymous FTP through these URLs: http://www.brics.dk ftp://ftp.brics.dk This document in subdirectory RS/06/4/ A Rational Deconstruction of Landin’s J Operator∗ Olivier Danvy and Kevin Millikin BRICS† Department of Computer Science University of Aarhus‡ February 28, 2006 Abstract Landin’s J operator was the first control operator for functional languages, and was specified with an extension of the SECD machine. Through a se- ries of meaning-preserving transformations (transformation into continu- ation-passing style (CPS) and defunctionalization) and their left inverses (transformation into direct style and refunctionalization), we present a compositional evaluation function corresponding to this extension of the SECD machine. We then characterize the J operator in terms of CPS and in terms of delimited-control operators in the CPS hierarchy.
    [Show full text]
  • An Interview with Tony Hoare ACM 1980 A.M. Turing Award Recipient
    1 An Interview with 2 Tony Hoare 3 ACM 1980 A.M. Turing Award Recipient 4 (Interviewer: Cliff Jones, Newcastle University) 5 At Tony’s home in Cambridge 6 November 24, 2015 7 8 9 10 CJ = Cliff Jones (Interviewer) 11 12 TH = Tony Hoare, 1980 A.M. Turing Award Recipient 13 14 CJ: This is a video interview of Tony Hoare for the ACM Turing Award Winners project. 15 Tony received the award in 1980. My name is Cliff Jones and my aim is to suggest 16 an order that might help the audience understand Tony’s long, varied, and influential 17 career. The date today is November 24th, 2015, and we’re sitting in Tony and Jill’s 18 house in Cambridge, UK. 19 20 Tony, I wonder if we could just start by clarifying your name. Initials ‘C. A. R.’, but 21 always ‘Tony’. 22 23 TH: My original name with which I was baptised was Charles Antony Richard Hoare. 24 And originally my parents called me ‘Charles Antony’, but they abbreviated that 25 quite quickly to ‘Antony’. My family always called me ‘Antony’, but when I went to 26 school, I think I moved informally to ‘Tony’. And I didn’t move officially to ‘Tony’ 27 until I retired and I thought ‘Sir Tony’ would sound better than ‘Sir Antony’. 28 29 CJ: Right. If you agree, I’d like to structure the discussion around the year 1980 when 30 you got the Turing Award. I think it would be useful for the audience to understand 31 just how much you’ve done since that award.
    [Show full text]
  • An Introduction to Landin's “A Generalization of Jumps and Labels”
    Higher-Order and Symbolic Computation, 11, 117–123 (1998) c 1998 Kluwer Academic Publishers, Boston. Manufactured in The Netherlands. An Introduction to Landin’s “A Generalization of Jumps and Labels” HAYO THIELECKE [email protected] qmw, University of London Abstract. This note introduces Peter Landin’s 1965 technical report “A Generalization of Jumps and Labels”, which is reprinted in this volume. Its aim is to make that historic paper more accessible to the reader and to help reading it in context. To this end, we explain Landin’s control operator J in more contemporary terms, and we recall Burge’s solution to a technical problem in Landin’s original account. Keywords: J-operator, secd-machine, call/cc, goto, history of programming languages 1. Introduction In the mid-60’s, Peter Landin was investigating functional programming with “Applicative Expressions”, which he used to provide an account of Algol 60 [10]. To explicate goto, he introduced the operator J (for jump), in effect extending functional programming with control. This general control operator was powerful enough to have independent interest quite beyond the application to Algol: Landin documented the new paradigm in a series of technical reports [11, 12, 13]. The most significant of these reports is “A Generalization of Jumps and Labels” (reprinted in this volume on pages 9–27), as it presents and investigates the J-operator in its own right. The generalization is a radical one: it introduces first-class control into programming languages for the first time. Control is first-class in that the generalized labels given by the J-operator can be passed as arguments to and returned from procedures.
    [Show full text]
  • Landin-Seminar-2014
    On correspondences between programming languages and semantic notations Peter Mosses Swansea University, UK BCS-FACS Annual Peter Landin Semantics Seminar 8th December 2014, London 1 50th anniversary! IFIP TC2 Working Conference, 1964 ‣ 50 invited participants ‣ seminal papers by Landin, Strachey, and many others ‣ proceedings published in 1966 2 Landin and Strachey (1960s) Denotational semantics (1970s) A current project 3 Peter J Landin (1930–2009) Publications 1964–66 ‣ The mechanical evaluation of expressions ‣ A correspondence between ALGOL 60 and Church's lambda-notation ‣ A formal description of ALGOL 60 ‣ A generalization of jumps and labels ‣ The next 700 programming languages [http://en.wikipedia.org/wiki/Peter_Landin] 4 1964 The mechanical evaluation of expressions By P. J. Landin This paper is a contribution to the "theory" of the activity of using computers. It shows how some forms of expression used in current programming languages can be modelled in Church's X-notation, and then describes a way of "interpreting" such expressions. This suggests a method, of analyzing the things computer users write, that applies to many different problem orientations and to different phases of the activity of using a computer. Also a technique is introduced by which the various composite information structures involved can be formally characterized in their essentials, without commitment to specific written or other representations. Introduction is written explicitly and prefixed to its operand(s), and The point of departure of this paper is the idea of a each operand (or operand-list) is enclosed in brackets, machine for evaluating schoolroom sums, such as e.g. Downloaded from 1.
    [Show full text]
  • SLS 2018 109Th Annual Conference, Queen Mary University of London
    SLS 2018 109TH ANNUAL CONFERENCE Law in troubled times Richard Taylor Professor of English Law Lancashire Law School University of Central Lancashire, Preston Vice-President, Society of Legal Scholars c/o Mosaic Events Ltd, Tower House, Mill Lane, Off Askham Fields Lane, Askham Bryan, York, YO23 3FS 01904 702165 [email protected] Final Programme Queen Mary University of London Tuesday 4th – Friday 7th September 2018 Follow the conference on Twitter @slsLondon2018 #slslondon18 CONTENTS WELCOME FROM SLS PRESIDENT 03 KEYNOTE SPEAKERS 04 GENERAL INFORMATION 05 SOCIAL PROGRAMME 07 SLS 2018 PROGRAMME 09 PROGRAMME SUMMARY 09 GROUP A SUBJECT SEssIONS 11 GROUP B SUBJECT SEssIONS 20 PUBLISHERS EXHIBITION 28 QUEEN MARY UNIVERSITY OF LONDON MAP 30 WELCOME From Peter Alldridge, SLS President Welcome to the The very onerous role of co-ordinating the Annual Conference of Subject Sections has been taken up this year the Society of Legal by Jamie Lee, and he has done a wonderful job Scholars. The theme in reconciling the various demands upon times of the conference and places. I would like to thank the Subject is ‘Law in Troubled Section Convenors for all their efforts. We Times’. This theme was are also grateful to all the excellent keynote chosen in mid-2017 speakers who enrich the conference with their and was prompted experience and insights. The major organisational by the events of roles have been undertaken, at rather shorter 2016 and 2017. notice than would have been ideal, by Mosaic Events of York, who have risen nobly to the A great deal of the legal landscape is changing challenge and the Society looks forward to a rapidly.
    [Show full text]
  • Speeches and Papers
    R. W. Bemer Speeches and P^ers 1979 On I qannotator/.field 07/27/82 14.252 MEDIA CODE 6 To: Geo rye Field# M S3 9-440 98* 248-72 38 From: Bob Bemer cc: Steve Kirk Subj: Papers Here is a list of my papers for qualification for the honoraria authorized by the Technical;Articles Program, Reprints or other establishing documents accompany this memo. 1. ~# "Information acquisition# storage# and retrieval in the office environment"# in St ate-of-the-Art Report 66# "Infor­ mation Technology"# Infotech International# Maidenhead# Berks.,# UK/ 1979 Nov 26-28# 7/1-7/13. #2. -# "Some history of text processing"# AFIPS Office Automa­ tion Conf.# Atlanta# 1 980 May 3-5. 3. -# "Office automation and invisible files"# Automati zione e I nst rume nt az i one ?# No. ?# 1 980 ?# ???# Italy. (do not have publication for reprint yet# but know it is published. Sci. Honeyweller has asked for an abstract.) ^Vj -# Presentation# Keynote Panel# 1980 NCC Personal Computing Festival# 1980 May 19. -# Presentation# 1980 NCC Pioneer Day Program (SHARE). (extensive summary published in Annals of the History of Cornputinj# Vol 3# No. 1# 1981.) -# "Incorrect data and social harm"# DATA Magazine# Copen­ hagen# 10# No. 9# 1980 Sep# 43-46. -# "File management for office automation"# Infotech State- of-the-Art Conference# London# 1980 November 26-28# Vol 2# 15-2,6. -# "New dimensions in text processing"# Interface '81# Las Vegas# 1981 Apr 01-02. -# "Problems and Solutions for Electronic Files in the Of­ fice"# Proc. A.I.C.A. Annual Conf.# Pavia# Italy# 1931 Sep 23-2 5 # 131-133.
    [Show full text]
  • Speeches and Papers
    ROOMS 1-2-3 THE IMPACT OF STANDARDIZATION FOR THE 70's (PANEL) ROBERT W. BEMER General Electric Company Phoenix, Arizona CHAIRMAN AND TECHNICAL PROGRAM CHAIRMAN'S MESSAGE , CONFERENCE AWARDS ' - Harry Goode Memorial Award 3 Best Paper Award 3 Best Presentation Award 3 TECHNICAL PROGRAM 4 CONFERENCE-AT-A-GLANCE (Centerfold) 52,53 CONFERENCE LUNCHEON 75 Luncheon Speaker 75 EDUCATION PROGRAM 76 SPECIAL ACTIVITIES 76 Conference Reception 76 Conference Luncheon 76 Computer Science and Art Theater 76 Computer Art Exhibit 77 Computer Music Exhibit 77 Scope Tour 77 LADIES PROGRAM 78 Hospitality Suite 78 Activities 78 GENERAL INFORMATION 79 Conference Location 79 MASSACHUSETTS INSTITUTE OF TECHNOLOGY PROJECT MAC Reply to: Project MAC 545 Technology Square Cambridge, Mass. 02139 June 5, 1969 Telephone: (617 ) 864-6900 x6201 Mr. Robert W. Bemer General Electric Company (C-85) 13430 North Black Canyon Highway Phoenix, Arizona 85029 Dear Bob: Thank you very much for your participation in my panel session at the Spring Joint Computer Conference. On the basis of a number of comments I received from both strangers and friends and also my own assessment, I think we had a successful session. I particularly appreciate your willingness to contribute your time and efforts to discussion of the problems of managing software projects. As I may have told you previously, I have been teaching a seminar on this same subject at M.I.T. A number of my students who attended the session were particularly interested in the presentations by the panelists. I would appreciate it if you could send me copies of your slide material for use in my class.
    [Show full text]