Daily, 2010/09/24-2010-09-29: closures and laziness

I got a bit behind this week, and being out of town on the weekend exacerbated the problem!  Here's three dailies in one, albeit short! 

Announcement items:

• A#3 out; pairings due TOMORROW evening!
• Reminder: the exam will be CLOSED BOOK but "open wiki appendix"
• Appendix is up: edit it!
• First 10 substantive edits: +1 BP!
  
  
• A#3 out by tomorrow; pairings due by Thursday evening!
• Important A#2 update: {- x y z} in example should have been {- {- x y} z}.
• Reminder: the exam will be CLOSED BOOK but "open wiki appendix"
• Vote on Dereck's office hours time (see Vista "assessments" area)
   
• Wiki appendix or open-notes/text? WINNER IS APPENDIX
• KEY midterm material today: closures (will make many practice Qs make more sense)
• Vote on Dereck's office hours time (see Vista "assessments" area)
  

High-level comment:

We built and admired closures, detoured to the fascinating power of lazy languages, and then came back to implementing laziness.. only to discover that closures gave us everything we needed for laziness!

Meanwhile, I continue to minimize the new code I write in class, which is making it easier to get to the key ideas, although I still find myself running a minute or two over!  It's hard not to linger on interesting bugs we run into as we proceed.  I could certainly fix these more rapidly without discussing them, but each one is an opportunity to model debugging practice and to explore the semantics of programs.  Ah.. the temptation!

I'm wondering how you all are doing with respect to the instructional style, particularly since I've been doing fewer active learning exercises (and, probably consequently, getting less class participation).  So, it's about time I did a survey.  Maybe Friday or Monday..

Details:


In resolving a major crisis (re-introduction of static scoping while implementing functions), we developed the most important conceptual tool in programming languages: closures.  On the foundation of closures, we can build a tremendous variety of other programming language tools, including object-oriented programming and continuations (which model exceptions and exception handling, among other things), to name a two big ones!

Closures provide powers like: deferring evaluation (the body), preserving context (the enclosed environment), encapsulating capabilities (again, through the enclosed environment), and limited but comprehensible "dynamic scoping" (via bindings to parameters).

We also explored the programming idioms enabled by laziness (in Haskell), particularly programming with infinite streams by creating and composing processes.

Implementing laziness turned out to be straightforward once we have closures.  After all, closures give us deferred evaluation and preservation of context, the two things we needed for laziness.  So, we just grab argument expressions to functions and encapsulate them in zero-argument closures ("expression closures" or "thunks") before sending them to the function.  Then, anywhere that a piece of code needs an actual value, it just calls our "strict" function to recursively force evaluation from expression closures to actual values.


Cheers,

Steve