Class 25: Preconditions, Revisited

Held: Monday, 6 March 2017

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

Preliminaries

Overview

• Verifying preconditions
• The error procedure
• Husk and kernel programming

Related Pages

• Eboard 25 (Source)

• Reading: Verifying Preconditions

• Lab: Verifying Preconditions

Updates

News / Etc.

• New partners!
• Quizzes returned; current grade status coming tonight.
• Welcome to any visiting prospective students.
  • Please introduce yourself.
  • You may ask the students in this class a question.

Rotating reminders

• Ask questions via email! I’m always happy to (try to) answer questions via email. There is no need to apologize when sending me questions. If I take too long to answer, send another email (or even text, if it’s a reasonable hour).

Upcoming Work

• Exam 2 due TOMORROW NIGHT
• Epilogue due Wednesday night
• Lab writeup: Exercise 3
• Reading: Characters and strings

Extra credit (Academic/Artistic)

• CS Table, Tuesday at noon, Generating poetry
  • Readings should be outside Curtsinger’s office
• CS Extras, Thursday at 4:15 pm, The CS curriculum
• Up to two of the events in the Rosenfield Technology and Human Rights symposium

Extra credit (Peer)

• Playboy of the Western World, next weekend (9th-12th).
• Ritalin Test Squad Friday the 10th.
• South Asia Tea Time Friday (?)
• G-Tones concert, March 12 with Opposed to Toy Trains (aka Con Brio), time tbd
• Grinnell Singers, March 12 at 2pm

Extra credit (Misc)

• Tuesday 11:00 a.m. discussion about controversial speakers

Good things to do

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