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 racket-users+unsubscr...@googlegroups.com. 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.
