2/22 announcements and reminders: + important: fill out Course & Prelim T1 evaluation (available by weekend) + i will adjust the course if results say i should + (results from lecture feedback say i'm a little too fast) + you may fill out anonymously + 1 bonus point for completing: go to separate online certification form + *even* if you filled out evaluation non-anonymously, + certify that you completed the evaluation form (honor system) + honestly answer question about programming background + many sources of help: use them! + lecture sketch and feedback form available later today + run the code! break it into smaller pieces! make changes! + P3 solutions by weekend, evaluation form activated late afternoon today + E6 posted later today; due online 8am Tuesday + please consider Bonus on E6: rewrite something from lecture, projects, T1 + P4 available Tuesday (one part is original P3.1, one is P3.4) + Catch-up Review Session 3pm, Sunday 2/25, Kimball B11 + as you should know from the Overview page: newsgroup is required topics + newsgroup demo: netscape *communicator* (navigator no good), WinVN + matlab demo: setting path, scripts, functions + key analogy for understanding functions + box scope diagram memory model for tracing functions + expected P3 approach _______________________________________________________________________________ newsgroup demo: netscape communicator + course webpage has some information and suggestions + generally, ask CIT for help + View menu + Sort + by Date: easily spot new posts + by Thread: see structure of replies + Messages [note: might not work in labs] + All: see both read and unread messages + Unread: see only messages you haven't read yet _______________________________________________________________________________ analogy for understanding functions + note: ProgramLive shows this process using animation purpose of functions, calling functions + (*function*) each student knows how to perform a specific task + (*call* or *invoke* by name) to get student to perform the task, shout his or her name + to model the computer program's limitations, no other talking allowed scope = "what can be 'seen'/'accessed'" + (functions can usually "see" each other: they are in the same *scope*) each student has a BIG piece of paper with everyone else's names + (a function call/invocation creates a new *scope*: an *activation record*) each time a student performs a task, he or she will somehow (see below) get a fresh piece of scratch paper on which to work things out + (function "sees" only its *local* variables and other functions: activation records are *disjoint* (non-overlapping)) a student can see only his or her own personal piece of scratch paper and the BIG piece of paper with everyone else's names -- cannot see any other pieces of paper, e.g. no sharing of scratch paper (paper airplanes don't count) + (scope rules: look at local scope before outer scope) students keep their scratch paper on top of the piece of paper with everyone else's name: they first try to find values on the scratch paper and only move on to BIG piece of paper if search fails on scratch paper + (local variables *shadow* functions with the same name) the order of search (scratch before BIG) means that if a variable on the scratch paper has the same name as a student, then that student cannot be called by the scratch paper's owner: he or she will find the scratch variable and thus never look at the BIG piece paper + (different functions can safely use local variables with same name) since different students have different pieces of scratch paper, they can't interfere with each other's work, even if they happen to use the same variable names example: suppose Irvin asks Igor to perform a task caller callee (call*ER*, *IR*vin) (call*EE*, *I*gor) printing versus passing and returning + (*display* or *print* a value) one action a student can take is to write something on the chalkboard + (program does-not-know/cannot-read what it prints/displays!) to model the computer program's limitations, pretend students cannot read the chalkboard! + no reading chalkboard + no talking ==> Irvin Igor + (*pass*) need way to send data from caller to callee: caller --> callee | V + (*return*) need way to send data from callee to caller: caller <-- callee Irvin Igor parameters, arguments, motivation + (a function can have *parameters* (special kind of variables), which must be provided values; values for parameters are *arguments*) to perform a task, a student might need to know certain specific values, e.g. "write _the_paragraph_ once in english and once in french on chalkboard": *which* paragraph? + Q: why have parameters that can be specified when the function is invoked? A: function probably won't be as useful if values are *hard-coded*, e.g. "write the first paragraph of Chapman 2.3 once in english and once in french on chalkboard" parameter passing: send specific values from caller to callee + Irvin, *caller* steps: + writes down the values (*arguments) sequentially but unlabeled on a fresh piece of paper, + folds it into an airplane, + shouts out the *callee*s name, + throws the paper airplane to the *callee* + halts performing task: waits for callee to finish + Igor, *callee* steps: + unfolds airplane + gives names to sequentially written down values + uses unfolded airplane for scratch work (as the activation record) return control, return values: send back answers and "i'm done" + when Igor, callee, is done: + (*return* values, which are called *return values*)) ( ^^^^^^ verb ^^^^^^ adjective) needs to send back any answers + (*return* control) needs to inform caller (Irvin) of completion so caller can stop waiting + Igor, callee: + copies answers from activation record sequentially but unlabeled onto a fresh piece of paper, + folds it into an airplane, + throws it back to caller Irvin *without* shouting a name, + burns own activation record. + Irvin, caller, remembers/knows who he is waiting for: + receives paper airplane and understands Igor, callee, finished + copies any answers from airplane onto own scratch paper + burns airplane + continues performing task from where he left off ! *nested* function calls ! + (one function can call another) ! ignoring shadowing, one student can call out any other student's name ! ! bonus concept: *recursion* ! + (a function calling itself) ! a student can call out his or her own name! _______________________________________________________________________________ preview of next lecture: ! box scope diagram memory model for tracing ! + (review 1/25 lecture if you don't remember the box diagram memory model) ! + extend to include function calls ! + basically, a summary of the analogy above ! ! scope rules -- to find an identifier (variable or function name): ! + look inside current scope ! (but do not look inside scopes within the current scope) ! + if find identifier, then done ! + else move to immediately enclosing scope. repeat search. ! + if there is no enclosing scope, then identifier is not found ! ! declaring (creating) a variable ! + create inside original scope (where search started) ! ! initial scopes: ! + a BIG enclosing scope with all the names of functions ! + matlab top-level (command window) scope ! + immediately within BIG enclosing scope ! + statements executed in command window run inside top-level scope, ! not the BIG enclosing scope ! ! function call ! 1. evaluate arguments ! 2. draw activation record (function name, box) ! at same scope the function is found (for now: immediately inside BIG scope) ! 3. inside activation record: write in parameters, fill in with argument values ! (1st parameter <-- 1st value, 2nd <-- 2nd, 3rd <-- 3rd, etc.) ! 4. run function body inside activation record ! 5. copy out return values ! 6. tear down activation record: cross out ! ! do not confuse *printing* a value with *returning* a value _______________________________________________________________________________ Q: can functions call other functions? A: yes Q: how do variables work when this happens? A: explained next lecture Q: does the callee wait for a response after returning scratch paper? A: no.