Тип безопасности в Clojure

Question

Я хочу спросить, какие типы языков безопасности типов существуют в Clojure?

Я уже несколько раз читал «Практическое Clojure» от Люка Вандерхарта и Стюарта Сьерры, но у меня все еще есть отчетливое впечатлениечто Clojure (как и другие списки) не очень серьезно относится к проверке во время компиляции.Безопасность типов - это всего лишь одна (очень популярная) стратегия проверки правильной семантики во время компиляции

Я задаю этот вопрос, потому что мне не терпится доказать, что я ошибаюсь;Какие шаблоны проектирования доступны в clojure для проверки (во время компиляции, а не во время выполнения), что функция, которая ожидает строку, не вызывается, скажем, со списком целых чисел?

Кроме того, я читал очень умных людей, таких как Пол Грэм, открыто выступающих за lisp, позволяющий реализовывать все, начиная с языков более низкого уровня, на его основе (большинство скажет, что сам язык переопределяется поверх него), так что если этоутверждение было бы правдой, тогда тривиальные вещи, такие как проверка типов, должны быть кусочком пирога. То есть вы чувствуете, что существуют системы типов (или возможность реализовывать такие системы типов) в clojure или других списках, которые дают программисту возможность сдвигать проверку правильности от времени выполнения к времени компиляции, или даже лучше?, время разработки?

Answer 1

Единицы компиляции в Clojure очень малы - единственная функция. Лисперс имеет тенденцию изменять небольшие части запущенных программ во время их разработки. Внедрение статической проверки типов в этот стиль разработки проблематично - для более глубокого обсуждения, почему я рекомендую пост Типы являются антимодульными от Гилада Брача. Таким образом, Clojure предпочитает предварительные / постусловия, которые лучше сочетаются с высоко REPL-ориентированная разработка.

Тем не менее, безусловно, желательно и возможно построить систему типа а-ля-карт для Clojure. Этот след был проложен Ци / Шеном и Typed Racket. Эта функциональность может быть легко предоставлена ​​в виде библиотеки. Я надеюсь построить что-то подобное в будущем с core.logic - https://github.com/clojure/core.logic.

Answer 2

Поскольку Clojure является динамическим языком, вся идея не в том, чтобы проверять типы (или многое из чего-либо) во время компиляции.

Даже когда вы добавляете подсказки типа в вашу функцию, они не проверяются во время компиляции.

Поскольку Clojure - это Lisp, вы можете делать все, что захотите во время компиляции, с помощью макросов, и макросы достаточно мощные, чтобы вы могли писать свои собственные системы типов. Некоторые люди сделали системы типов для рюкзаков Typed Racket и Qi . Эти системы типов могут быть такими же мощными, как и любая система типов на «нормальном» языке.

Хорошо, теперь мы знаем, что это возможно, но есть ли у Clojure такая необязательная система типов? В настоящее время нет ответа, но есть логический механизм (core.logic), который можно использовать для реализации системы типов, но автор еще не работал (*) в этом направлении.

Answer 3

Есть библиотека, которая добавляет опциональную систему типов к Clojure,

http://typedclojure.org/

Обоснование

Статическая типизация имеет хорошо известные преимущества. Например, статически типизированные языки отлавливают много общих ошибок программирования в самое ближайшее время: время компиляции. Типы также служат отличной формой (проверяемой компьютером) документации, которая почти всегда дополняет существующую рукописную документацию.

Языки без статической проверки типов (с динамической типизацией) дают другие преимущества. Без строгой жесткой обязательной статической типизации они могут обеспечить более гибкие и прощающие идиомы, которые могут помочь в быстром прототипировании. Часто преимущества статической проверки типов желательны по мере роста программы.

Эта работа добавляет статическую проверку типов (и некоторые ее преимущества) к Clojure, динамически типизированному языку, сохраняя при этом идиомы, которые характеризуют язык. Он позволяет смешивать статический и динамически типизированный код, чтобы программист мог использовать любой более подходящий вариант.