[racket] Why check-expect only at the top level?

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