6.001: WEEKLY OUTLINE FOR STAFF Spring 1998 First Staff meeting: Thursday, January 29, 1998 A. Administrivia 1. Staff Introductions Assignment of Tutors to Offices Collection of Information Names, Office Addresses, Office Telephones, Home Telephones 2. Staff Meetings Time for subsequent meetings -- Tuesdays after lecture Plan of a meeting Administrivia The coming Week Gripes, Staff reports 3. Assignment of Staff to Recitation Sections 4. Description of Duties 4.1 of Tutors Attendance at Lectures, Recitations, staff meetings TUTORIALS Supplementary Laboratory Coverage Doing the problem sets in advance Grading Problem Sets, Labs, Quizzes Maintainance of Grade Sheets (do NOT put grades on the Web unless you use random IDs--not MIT IDs) Preparing one problem set solution Bringing lecture material to lecture once or twice (schedule this) Spend some time in the Lab Run recitation at least once, with instructor present It is NOT a TA responsibility to cover recitation if instructuctor cannot be there. 4.2 of Lab assistants Final check out of problem sets on all supported implementations Monitor and administer 6.001 Discussion Forum Principal Laboratory Supervision 6.001 Help Service (beepers) Maintainance of Software, except for substantive changes Quiz reviews Lab assistants' meetings 4.3 of recitation instructors Attendance at lectures, recitations, staff meetings Doing the problem sets Grading quizzes Primary responsibility for recommending grades Providing feedback to students at mid-semester Organizing and coordinating student oral presentations in recitation, and providing feedback. Feedback sheets Observation of tutor teaching recitations at least once. Fill-in converage of recitations is NOT a Tutor responsibility Run tutorials at least once. (Discuss procedure on what happens when instructors have to be out of town.) 5. Problem Sets, microquizzes, and oral assignment for recitation Questions are responsibility of Lecturer Answer Sheet Preparation rotates among tutors Problem set pipeline Due two weeks before student answers so that we catch any bugs before the PS goes to press. Consider how students will go wrong and comment Assignment of responsibility 6. Quizzes --- mark times now, both for proctoring and grading 7. Grades: Problem sets, Quizzes, Final Exam 8. Special meeting for Tutors 9. Lab assistants' meeting 10. Special notes: Supported implementations for this semester. Recommended way students should work. 11. Overview of grading policy (tutors must not make "deals" about grades) 12. Sex and true love 13. Discussion of teaching style in recitations and tutorials - support material (Torch or Firehose; 53 Interesting Things) - room arrangement - getting students to speak - oral presentations - weekly microquizzes - getting tutors to stop speaking B. Organization and Coverage of Subject 1. Calendar 2. Major divisions of subject Projected changes for this semester C. First week Lecture 1: Tuesday, Feb 3, 1997 (Eric and Hal) Overview of subject Adminitrative details Primitives procedures and combinations Expressions as trees Define Lambda There is no staff meeting on February 4th, but tutors must meet after lecture on Thursday to assign sections and keyboard in section lists. Assignments will be posted on the web BY ID NUMBER, not name. Lectuers will prepare microquiz 1. This will be available from Becky by Thursday, Feb. 6. Everyone should do problem set 1 before the first lecture. Everyone should go through the course web page--- http://mit.edu/6.001 Recitation 1: Wednesday, Feb 5, 1997 ******************************************************************** Please take a head count and send Becky a note as soon as you are done with recitations -- we need to figure out how badly oversubscribed we are going to be. ******************************************************************** Get input from students on schedules, so that you can schedule tutorials. Emphasize that tutorial attendance is mandatory. Review policy on cooperative work. Discuss procedure on oral presentations and assign one for Friday. (Assign more on Friday.) Go thru a short computation showing that since there are about 420 students and only about 46 workstations there will be a crunch unless we schedule our work appropriately. Start working on a problem set early, and DO NOT TRY TO DO IT SITTING AT A TERMINAL. Prepare your work carefully before sitting down to crunch. Talk about the different Scheme implementions and suggested way of working. Mention the help number and the Scheme discussion forum. discussion forum password in 10-250. Help number is ??????. Point students at Web page. ******************************************************************** Explain the READ-EVAL-PRINT structure of the interpreter, and illustrate some simple numerical expressions (* 2 (+ 3 4)) Show how to use the editor to define a simple procedure: (define square (lambda (x) (* x x)) Cover some of the points of syntax, as explained in the teacher's manual such as the (mis)use of spaces and extra parentheses in writing combinations. and maybe step through the consequences of simple bug: (define (cube x) (*x x x)) ERROR -- UNBOUND VARIABLE *X Point out that problem set 1 is a simple exericse to get people familiar with the system, and people should do it soon. Go over: Essential syntax of Lisp-like languages -- ( ...) e.g. (+ 1 (* 2 3) 4) Idea of an interpreter, and what it means to interact with one read-eval-print loop errors and understanding error comments logging in logging out aborting bad computations Integration of interpreter with editor -- editor zap commands Do some exercises that have the purpose of getting students to interact and talk. Example: pyramiding. Lection 2: Thursday, Feb 5 (Jim) Introduction to Lisp (Scheme) Jim's mantras Primitives Data Numbers Procedures Simple numerical procedures: +, -, *, /, >, ... Means of combination Prefix notation Composition Expressions as trees Means of abstraction Global definitions -- DEFINE Variables as a controlled excape from tree structure Procedural variables, LAMBDA expressions Compound procedures case analysis COND, IF The substitution model applicative order normal order Modularity Abstraction Variables Local Variables Block structure Example SQRT -- wishful thinking Recitation 2: Friday, Feb 7 ******************************************************************** Please take attendance and point displaced persons in the right direction. A master list of sections will be available from Jill and also posted outside the 6.001 lab. Recitation changes are up to Jill. Instructors cannot make changes on their own. ******************************************************************** Tutors should get any updates to schedules from students, so that they can announce tutorial assignments by early next week. Tutorials start the following week. Practice with Defining Procedures for example: given N and B, find the largest power of a B less than N More Help With System Use Substitution model. Do normal order versus applicative order, if we don't get to it in lecture ******************************************************************** First microquiz First oral presentation Ask students to predict what COUNT1 and COUNT2 will do when applied to 4 (define (our-display x) (display x) x) (define (count1 x) (cond ((= x 0) 0) (else (our-display x) (count1 (- x 1))))) (define (count2 x) (cond ((= x 0) 0) (else (count2 (- x 1)) (our-display x)))) Points to notice: A procedure body can be a sequence of things to do, and the value returned is the value of the final expression. Note that the things in COUNT are displayed by OUR-DISPLAY, and the final result is displayed by the read-eval-print loop. The reason we use OUR-DISPLAY rather DISPLAY directly is that there is a tricky confusion...In our implementation of Scheme, the value of PRINT is a special value called no-value. You can explain that DISPLAY returns something weird and for the example we want to return something sensible. The major thing to get across is that EVERYTHING returns a value, and that normally we don't need to explicitly include any print commands in order to see the result of an evaluation. We have already used this implicitly in block-structured SQRT. A related point is that <, =, etc. also return values. Explain that IF and COND only care whether something is false. #T just happens to be a random non-false value returned by some predicates in our implementation. Note the syntactic detail that the consequents in COND clauses can be sequences, but IF clauses cannot be sequences. (Unless you explicitly use BEGIN, but we don't introduce this until chapter 3 -- page 170.) Also note that, when we deal with sequences and actions (like PRINT) the substitution model is not wonderfully instructive.