Создание решающих правил

Проверьте запуском

(define (refund-decision days opened?)
  (if (and (<= days 14) (not opened?))
      '(decision allow)
      '(decision deny outside-refund-window)))
(refund-decision 9 #f)

(decision allow)

Разберите приём

1. Назовите каждый вход. days и opened? поступают как обычные данные; правило не выполняет скрытого поиска.
2. Покажите границу. Четырнадцать дней допускаются через <=, поэтому первое отклоняемое значение — 15.
3. Возвращайте помеченные данные. Результат называет решение, а при отказе — причину, которую может проверить приложение.

Как рассуждать

• Держите преобразование host-данных вне правила и закрепляйте точный datum, переданный проверяемому профилю.
• Возвращайте компактное значение с документированной приложением интерпретацией и тестируйте обе границы.
• Версионируйте исходник, корпус ввода и квитанции вместе, чтобы replay имел явный знаменатель.
• Когда решающее правило стабильно, кодируйте его точные проверенные байты в изображение Lispex для детерминированной визуальной передачи. Обычный исходник остаётся поверхностью ревью и контроля версий.

Проверьте себя

Что вернёт правило для (refund-decision 14 #f), (refund-decision 15 #f) и (refund-decision 9 #t)?

Частая ошибка

Квитанция решения не определяет справедливость или правильность самой бизнес-политики.

Куда дальше

Урок первого проекта строит и проверяет правило с нуля. Изображение Лиспекса переносит точный проверенный исходник, не меняя смысл.

Первое решающее правило · Изображения Лиспекса