Held: Monday, 27 October 2014

Back to Outline 29 - Numeric Recursion. On to Outline 31 - Naming Local Procedures.

Summary

We revisit preconditions. We then consider programming techniques for ensuring that preconditions are met.

Related Pages

• Reading: Verifying Preconditions
• Lab: Verifying Preconditions
• EBoard 30 (Source 30) (HTML 30)

Overview

• Verifying preconditions.
• The error procedure.
• Husk and Kernel programming.

Administrivia

• New partners!
• Welcome back. I hope you had a wonderful break!
• Congratulations to our own BM for an interesting writeup: http://www.grinnell.edu/news/attitude-gratitude
• A correction on my interpretation of College policies on academic honesty: I told you that if you don't turn in work, then you cannot be charged for academic dishonesty on that work. While the chair of the CAS subcommittee on academic dishonesty agreed with me that it was appropriate to tell you that for my take-home exams, the dean who serves on that committee told me that that policy does not always apply. So don't count on it. (I don't expect that you will ever need to count on that rule, but I don't want to mislead you if you find that you want to.)
• HW 6: If you want to work by yourself or with a particular person, please let me know by 10 pm tonight using http://bit.ly/151-2014F-partners6. Otherwise, I will assign you a randomly selected partner.

Work Returned

• HW 5 returned via email.
  • Folks aren't documenting.
  • But I haven't been reminding you to document.
  • You should plan to document on HW 6.
• Quiz 7 returned.
  • Each db pic has a number. The images were arranged by number.
  • Whenever we hit a bad design in gigls and someone asks why it's not fixed, my standard answer is "I'm lazy".
• Exam 2 to be returned at the end of class.
  • If you needed to invoke "There's more than life", please sign up for an appointment. (Read through the notes on the exam before meeting with me.)

Upcoming Work

• Lab writeup: Problems 3h and 4 http://bit.ly/151-2014F-w30
• Reading for tomorrow.
  • Local Procedure Bindings
• Homework 6 (to be assigned on Wednesday), due a week from Tuesday.
• Exam 3, distributed a week from Wednesday, due two weeks from Tuesday.

Extra Credit Opportunities

Academic

• CS Extra Thursday: Randomness in Computer Science.

Peer Support

• Football (Saturday at 1pm)
• Karan's radio show 11pm Thursday nights on KDIC
• Evan's radio show 5pm Friday nights on KDIC
• Donna's radio show Sunday midnight on KDIC

On Meeting with SamR

Some of you meet with me regularly. Some of you just asked for help on the exam. Some of you don't meet with me at all. I hear from our upper-level students that meeting with me was helpful when they were in 151.

• So, I'm going to leave the room for five minutes and let you talk to each other about asking me for help in person or via email.
• You can also make a list of things that I can do better in meeting with students or responding to email, other than magically finding time for more office hours (or to clean my office).

Preconditions

• Remember: Documentation is a contract, be careful.
• Even if you don't write documentation (or don't write careful documentation), you should reflect on your expectations for parameters.
• We call those expectations the preconditions of the procedure.
• In some cases, you may want to explicitly test to ensure that the preconditions are met.
  • Testing lets you provide more useful error messages.
  • Testing prevents dangerous results from being returned.

Reporting Failure

• When a precondition fails, you want to stop computation immediately and report the error.
• In Scheme, you can do so with error or throw
  • The one to use depends on the version of Scheme you are using.
  • Our Scheme interpreter uses error

Husk and Kernel Programming

• Particularly for recursive procedures, it is inefficient to check preconditions at every recursive call
  • If the preconditions were met for the first call, they should be met for every subsequent call.
• Hence, programmers tend to use what I refer to as "Iowa's Great Contribution to Programming": The Husk-and-Kernel approach
  • The husk checks the preconditions and, if all preconditions are met, calls the kernel.
  • The kernel does the real work.
• Corn serves as the metaphor: The husk protects the kernel, and the kernel is the valuable part.
  • And no, Husk-and-Kernel programming was not invented in Iowa.

Lab