Чем отличия Racket Scheme от «дизайн по контракту» отличаются от Eiffel?

Question

Я знаю, что и Eiffel (прародитель), и Racket для реализации функций "Проектирование по контракту". К сожалению, я не уверен, как один будет отличаться от другого. DBC Эйфеля зависит от парадигмы ООП и наследования, но как Racket, совсем другой язык, объясняет такое несоответствие?

Answer 1

Основная претензия Racket к контрактной славе - это понятие вины, и, безусловно, работа с функцией ho является важной частью повседневного программирования Racket.

Возможно, вы также захотите проверить первые два раздела этой статьи:

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

Answer 2

Прежде всего, вашим лучшим источником информации на данный момент является Руководство по ракеткам , которое предназначено как вводный текст, а не как справочное руководство.В частности, существует обширная глава о контрактах , которая может помочь.РЕДАКТИРОВАТЬ: Также см. Документ, на который указал Робби, он главный парень контракта Racket.

Что касается вашего вопроса - я не знаю много о системе контрактов Eiffel, но я думаю, что она предшествует системе Racket,Однако (и это снова «IIRC»), я думаю, что система контрактов Racket была первой, которая ввела контракты более высокого порядка.В частности, когда вы имеете дело с функциями более высокого порядка, назначение правильной вины становится немного более сложным - например, если вы берете функцию foo с контрактом X? -> Y? и отправляете ей значение, которое не соответствует X? тогда виноват код клиента, который отправил это значение на foo.Но если ваша функция (X? -> Y?) -> Z? и предикат X? не удовлетворен, то вина ложится на саму foo, а не на клиента (а если Y? не удовлетворяется, то вина по-прежнему лежит на клиенте).

Answer 3

Я думаю, вы спрашиваете, как система контрактов может работать без ООП и наследования? Как пользователь Racket, который не знаком с Eiffel, я удивляюсь, почему система контрактов имеет какое-либо отношение к ООП и наследованию. :)

На практике я считаю контракты Racket способом получения некоторых преимуществ статических объявлений типов, сохраняя при этом гибкость динамически типизированных языков. Плюс контракты выходят за рамки просто типов и могут выполнять роль утверждений.

Например, я могу сказать, что функция требует один аргумент, который является точным целым числом ... но также сказать, что это должно быть точное положительное целое число, или объединение определенных конкретных значений, или фактически любой произвольно сложный тест пройденного значения. Таким образом, контракты в Racket сочетают в себе то, что вы могли бы сделать с (a) объявлениями типа и (b) утверждениями, скажем, C / C ++.

Одна проблема с контрактами в Racket - это то, что они могут быть медленными. Один из способов справиться с этим - сначала использовать их при разработке, а затем выборочно удалять их, особенно из типов функций «внутреннего цикла». Другой подход, который я пробовал, заключается в том, чтобы включить или выключить их оптом: создайте пару модулей, таких как contract-on.rkt и contract-off.rkt, где последний предоставляет некоторые макросы, которые ничего не делают. Ваши модули требуют контрактов.rkt, который предоставляет все из файлов -on или -off. Это похоже на компиляцию в режиме DEBUG vs RELEASE.

Если вы приехали из Eiffel, возможно, мой уклон на C / C ++ для контрактов на Racket не поможет, но я все равно хотел поделиться им.