[racket] Top-down design, wish-lists, and testing

On Nov 22, 2010, at 11:06 AM, Matthias Felleisen wrote:

> 
> Thanks, we're on it. The syntax will be 
> 
> (define-wish identifier [expression])
> 
> The presence of an expression will turn it into option B. 

Is there a way to attach a contract (at least a number of parameters, if not type information)?  This would then feel sorta like a C/C++ function prototype :-)


There are Java-based CS1 books that teach you to ALWAYS write an "interface" before writing a class that implements it.  Similarly, it's fairly common in C/C++ programming to write function prototypes before writing function definitions (and the conceptually-one-pass compiler encourages this).

So doesn't a "checkable contract" serve the purpose of define-wish?

The design recipe would be modified in two ways:
1) for simple functions, you write a checkable contract rather than a contract-in-a-comment.
2) for functions that you didn't know you needed until part way through the assignment, you immediately write a checkable contract for the new function (with either no body at all, "...", or a stub value), then go on with the function that uses it, which can be checked at least for number of arguments.  Later on, you come back to it, write test cases (which still won't work, but at least can be checked for type and number of arguments), then write a real body.


Stephen Bloch
sbloch at adelphi.edu