Что composability означает в контексте функционального программирования?

Композиция в информатике - это способность собирать сложное поведение путем агрегирования более простого поведения. Функциональная декомпозиция является примером этого, когда сложная функция разбивается на более мелкие, легкие для понимания функции и собирается в окончательную систему функцией верхнего уровня. Можно сказать, что функция верхнего уровня «объединила» части в целое.

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

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

Другой пример: рассмотрим асинхронное программирование в .NET. Если вы используете такой язык, как C #, и вам нужно выполнить серию асинхронных (неблокирующих) вызовов ввода-вывода через API Begin / End, то для вызова двух операций, Foo и Bar , вы должны последовательно предоставить два метода ( BeginFooAndBar , EndFooAndBar ), где BeginFooAndBar вызывает BeginFoo обратный вызов Intermediate и Intermediate затем вызывает BeginBar , и вы должны передать промежуточные значения и IAsyncResult информацию о состоянии через, и если вам нужен блок try - catch вокруг всего этого, тогда удачи, вам нужно продублировать код обработки исключений в трех местах, yikes, и это ужасный беспорядок.

Но с F # есть тип async , построенный поверх функциональных продолжений, которые можно компоновать, и поэтому вы можете писать, например,

let AsyncFooAndBar() = async {
    let! x = Async.FromBeginEnd(BeginFoo, EndFoo)
    let! y = Async.FromBeginEnd(BeginBar, EndBar, x)
    return y * 2 }

или что у вас есть, и это просто, и если вы хотите поместить вокруг него try - catch , отлично, код находится в одном методе, а не распространяется напротив трех, вы просто помещаете вокруг него try - catch , и он работает.

Я согласен с ответом Марсело Кантоса, но я думаю, что он может предполагать больше знаний, чем есть у некоторых читателей, что также связано с тем, почему композиция в функциональном программировании особенная. Состав функций функционального программирования по существу идентичен составу функций в математике. В математике у вас может быть функция f (x) = x ^ 2 и функция g (x) = x + 1 . Составление функций означает создание новой функции, в которой аргументы функции передаются «внутренней» функции, а вывод «внутренней» функции служит входом для «внешней» функции. Составив f внешний с g внутренним, можно записать f (g (x)) . Если указать значение 1 для x , тогда g (1) == 1 + 1 == 2 , поэтому f (g ( 1)) == f (2) == 2 ^ 2 == 4 . В более общем смысле, f (g (x)) == f (x + 1) == (x + 1) ^ 2 . Я описал композицию, используя синтаксис f (g (x)) , но математики часто предпочитают другой синтаксис, (f. G) (x) .Я думаю, это потому, что это проясняет, что f, составленный с помощью g , является самостоятельной функцией, которая принимает единственный аргумент.

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

Вот реальный пример. Имена всех людей, живущих в вашем доме, - это список имен всех мужчин в вашем доме в сочетании со списком всех женщин в вашем доме.

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

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

Простым примером композитивности является командная строка Linux, где символ pipe позволяет комбинировать простые команды (ls, grep, cat, more и т.д.) практически неограниченным количеством способов, таким образом "составляя" большое количество сложных моделей поведения из небольшого количества более простых примитивов.

Композиционность имеет несколько преимуществ:

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

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

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

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

По аналогии, меньшее количество типов данных дает большую композитивность. Рич Хикки из Clojure сказал что-то вроде

каждый новый тип объекта по своей природе несовместим со всем когда-либо написанным

, что, безусловно, хорошо сказано.

Практическая совместимость также зависит от стандартизации небольшого набора типов данных, как это делают команды Unix со своим стандартом "текст, разделенный табуляцией на строки".

Postscript

Эрик Реймонд написал книгу о философии Unix, два из перечисленных им принципов проектирования были

• Правило модульности: Пишите простые части, соединенные чистыми интерфейсами.
• Правило композиции: Создавайте программы так, чтобы они были связаны с другими программами.

Из http://catb.org/~esr/writings/taoup/html/ch01s06.html#id2877537

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