We all are indeed at Racket school.
The arguments for/against contracts have been made over and over again especially by Betrand Meyers, before we even introduced and studied the higher-order boundary-tied variant. + Contracts separate the core functionality of a service module from its assumptions. + Contracts can be read separately as API specs ~~ no need to read the code of a function/class/method. + Contracts are more concise than manual checks and they are collected in a single space. + Contract error messages are systematically generated and readable. + An improvement to the contract system automatically benefits all contracts. - Contracts might occasionally impose a small performance overhead over manual contracts. (They might also be faster if they can communicate with the compiler.) - Contract boundaries are somewhat “stiff” as Oak says in his email. Contributions for boundary re-factorings in DrRacket are welcome. Now you need to choose which dis/advantages you prefer — Matthias -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/A8D728B0-3623-4E85-89DD-66ACE67549CA%40felleisen.org. For more options, visit https://groups.google.com/d/optout.
