Принципы, Лучшие практики и Шаблоны разработки для функционального программирования

Why Functional Programming Matters by John Hughes gives good motivation for why laziness and higher order (first class) functions provide a lot of what less functional languages are missing and supplement with design patterns.

In the context of Haskell, I thought the book Real World Haskell had some good and practical advice about idioms and abstraction and type classes and the like. The Typeclassopedia is also always useful. The core, very abstract type classes could be looked at as design patterns except they are enforced by the compiler/type system and part of the language (if you learn how to use them).

In the context of Lisp, Paul Graham wrote a book called On Lisp (available online) where he shows that functional languages are ideal to create a custom programming language and then write your program in that. So embedded domain specific languages themselves are a sort of design pattern.

Есть складки, разворачивания, карты и т. Д.

Я считаю, что использовать их как лучшую практику, так как довольно легко рассуждать об их поведении, и они часто сообщают о цели функции. (например, просто взгляните на знаменитую Эволюцию программиста на Haskell и сравните новичка со старшим и с профессором).

Лучшая практика: используйте алгебраические типы данных и воспользуйтесь преимуществом проверки полноты от компилятора сопоставления с образцом. В частности,

• Никогда не совпадать с шаблоном подстановки _ на верхнем уровне.

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

Шаблон проектирования: позвольте типам определять ваше кодирование .

1. Выясните, какой тип вы пытаетесь вернуть.

2. Знайте, что определенные конструкторы типов имеют определенный синтаксис , и используйте его, чтобы уменьшить желаемый тип. Вот два примера:

   • Если вы пытаетесь вернуть тип функции T1 -> T2 , всегда безопасно писать

      \ x -> ...
     

     Теперь в теле вы пытаетесь создать значение типа T2 , которое является меньшим типом, плюс вы получили дополнительное значение x типа T1 , что может облегчить вашу работу.

     Если лямбда окажется ненужной, вы всегда можете уменьшить ее позже.

   • Если вы пытаетесь создать пару типов ( T1, T2) , вы всегда можете попытаться создать значение x типа T1 и значение y типа T2 , затем сформируем пару (x, y) . Опять же, вы уменьшили проблему до одной с меньшими типами.

3. Как только типы станут настолько маленькими, насколько вы можете их сделать, посмотрите на типы всех переменных let-bound и lambda в области видимости, и посмотрите, как вы можете создать значение нужного вам типа. Обычно вы ожидаете использовать все аргументы для всех функций; если нет, то обязательно объясните почему.

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

Шаблон проектирования: позвольте компилятору вывести типы для ваших функций и убедитесь, что эти типы в точности такие общие, как вы ожидаете. Если типы более или менее полиморфны, выясните, почему.

Например, если вы пишете функцию сортировки на Haskell, ожидайте

Ord a => [a] -> [a]

. Если ваш тип

Num a => [a] -> [a]

или

[a] -> b

, то что-то ужасно неправильно .

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

Не следуй принципам, следуй своему носу. Делайте функции короткими. Ищите способы уменьшить сложность кода, что часто, но не обязательно, означает максимально сжатый код. Узнайте, как использовать встроенные функции высшего порядка.

Выполните рефакторинг и уменьшите размер кода функции сразу после того, как вы ее написали. Это экономит время, потому что завтра у вас уже не будет проблемы и решения.