Racket Scheme的“按合同設計”與Eiffel有何不同？

Question

我知道Eiffel（祖先）和Racket都實現了“按合同設計”功能。 可悲的是，我不確定一個與另一個有何不同。 埃菲爾（Eiffel）的DBC依賴於OOP范式和繼承，但是Racket（一種非常不同的語言）如何解釋這種差異呢？

Answer 1

Racket贏得合同聲譽的主要主張是怪罪的概念，並且肯定地，處理ho函數是日常Racket編程的重要組成部分。

您可能還需要查看本文的前兩部分：

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

Answer 2

首先，到目前為止，您最好的信息來源是《 球拍指南》 ，該指南旨在作為介紹性文本，而不是參考手冊。 具體而言，有一章關於合同的廣泛章節會有所幫助。 編輯：還看到羅比指出的論文，他是球拍合同的主要負責人。

關於您的問題-我對Eiffel合同系統了解不多，但我認為它先於Racket的系統。 但是，（又是“ IIRC”），我認為Racket的合同系統是第一個引入高階合同的系統。 具體來說，當您處理高階函數時，分配適當的責備會變得更加復雜-例如，如果您選擇的foo函數的合同為X? -> Y? X? -> Y? 並且您發送的值與X?不匹配X? 然后就foo將此值發送給foo的客戶端代碼了。 但是，如果您的函數是(X? -> Y?) -> Z? 和X? 謂詞不滿足，則責任歸咎於foo本身，而不是客戶（如果不滿足Y?則責任仍由客戶承擔）。

Answer 3

我想您是在問，沒有OOP和繼承的合同系統如何運作？ 作為不熟悉Eiffel的Racket的用戶，我想知道為什么合同系統與OOP和繼承有關。 :)

從實際的角度來看，我認為Racket契約是一種在保持動態類型語言靈活性的同時獲得靜態類型聲明的某些好處的方法。 另外，合同不僅限於類型，還可以充當斷言的角色。

例如，我可以說一個函數需要一個參數，它是一個精確的整數...但也可以說它應該是一個精確的正整數，或者是某些特定值的並集，或者實際上是對傳遞的值進行任何任意復雜的測試。 這樣，Racket中的合同就可以將您在（a）類型聲明和（b）C / C ++中的斷言兩者結合起來。

在球拍中與合同打交道的一個陷阱是，它們可能很慢。 一種解決方法是，在開發時首先使用它們，然后有選擇地將其刪除，尤其是從“內環”類型的函數中刪除它們。 我嘗試過的另一種方法是打開/關閉它們：制作對模塊，例如Contracts-on.rkt和contract-off.rkt，后者提供一些無作用的宏。 讓您的模塊需要一個Contracts.rkt，它可以提供-on或-off文件中的全部文件。 這就像在DEBUG vs RELEASE模式下進行編譯。

如果您來自埃菲爾鐵塔，也許我對Racket合同的C / C ++傾向不會有幫助，但我還是想與您分享。