How does Racket Scheme's "design by contract" features different from Eiffel?

Question

I know that both Eiffel (the progenitor) and Racket both to implement "Design by Contract" features. Sadly, I am not sure how one would different from the other. Eiffel's DBC is reliant on the OOP paradigm and inheritance, but how would Racket, a very different language account for such a disparity?

Answer 1

Racket's main claim to contract fame is the notion of blame, and dealing with ho function is a big part of that for everyday Racket programming, definitely.

You might also want to check out the first two sections of this paper:

http://www.ccs.neu.edu/scheme/pubs/oopsla01-ff.pdf

Answer 2

First of all, your best source of information at this point is the Racket Guide, which is intended as an introductory text rather than a reference manual. Specifically, there is an extensive chapter about contracts that would help. EDIT: Also see the paper that Robby pointed at, he's the main Racket contract guy.

As for your question -- I don't know much about the Eiffel contract system, but I think that it precedes Racket's system. However (and this is again an "IIRC") I think that Racket's contract system was the first one that introduced higher order contracts. Specifically, when you deal with higher order functions assigning proper blame gets a little more complicated -- for example, if you take a foo function that has a contract of X? -> Y? and you send it a value that doesn't match X? then the client code that sent this value to foo is blamed. But if your function is (X? -> Y?) -> Z? and the X? predicate is not satisfied, then the blame goes to foo itself, not to the client (and if Y? is not satisfied then the blame is still with the client).