I suspect everyone who teaches has run into just such a desire. But there's a "when" problem.
We WANT students to be able to write checks before they write the function. That means their file can look like (check-expect (f 10) ...) (define (f x) ...) But if check-expect's just ran like regular code, this would no longer work. So c-e effectively rewrites the file to ... everything else ... ... all the c-e's, wrapped in reporting code ... (as you note in the excerpt you quote). The problem with such a scheme is that it's not immediately clear what to do with those inner c-e's. It's tricky to extract them to the top-level; also, since they are under a lambda, they presumably aren't run until the function does. But that means the expectation that all c-e's were run has been violated. One could imagine alternate interpretations of c-e, but the current one is simple, consistent, and useful. One possibility is that you want to implement some kind of "internal-check-expect" that has the semantics you have in mind; another is that you want to move past c-e to talking about testing and predicates, which is a bigger discussion. An assignment like this may then be of interest: http://www.cs.brown.edu/courses/cs019/2010/assignments/oracle Shriram _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
