Функции, которые выглядят чистыми для вызывающих абонентов, но внутренне используют мутацию

Я думаю, что почти каждый недостаток побочных эффектов связан с «взаимодействием с другими частями программы». Сами по себе побочные эффекты неплохие (как говорит @Gabe, даже чистая функциональная программа постоянно мутирует ОЗУ), это общие побочные последствия эффектов (нелокальные взаимодействия), которые вызывают проблемы (с отладкой / производительностью / понятностью /так далее.). Таким образом, влияние на чисто локальное состояние (например, на локальную переменную, которая не исчезает) в порядке.

(Единственный недостаток, о котором я могу думать, это то, что когда человек видит такую ​​локальную изменяемую переменную, он должен подумать о том, может ли она ускользнуть. В F # локальные изменяемые никогда не могут ускользнуть (замыкания не могут захватывать изменяемые), поэтому единственный потенциал " интеллектуальный налог "происходит из рассуждений об изменяемых ссылочных типах.)

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

(Если вы хотите углубиться в подробности, локальные эффекты, подобные тем, которые используются в реализации List.map в F #, не только не препятствуют параллелизуемости, но и являются преимуществом с точки зрения того, что более эффективная реализация выделяет меньше и, следовательно, меньше нагружает общий ресурс сборщика мусора.)

Возможно, вас заинтересует " Ленивые потоки функционального состояния ". Я проработал только первые несколько страниц, которые очень ясны (я уверен, что все остальное тоже очень ясное).

Важным моментом является то, что когда вы используете Control.Monad.ST для выполнения подобных действий в Haskell, система типов сама обеспечивает инкапсуляцию. В Scala (и, вероятно, F #) подход больше похож на «просто поверьте нам, что мы не делаем здесь ничего хитрого с этим ListBuffer в вашем map».

Если функция использует локальные, частные (для функции) изменяемые структуры данных, распараллеливание не затрагивается. Поэтому, если функция map внутренне создает массив размера списка и выполняет итерацию по его элементам, заполняя массив, вы все равно можете запускать map 100 раз одновременно в одном и том же списке и не беспокоиться, потому что каждый экземпляр map будет иметь свой собственный частный множество. Поскольку ваш код не может видеть содержимое массива, пока он не будет заполнен, он фактически чистый (помните, что на каком-то уровне ваш компьютер должен фактически изменить состояние ОЗУ).

С другой стороны, если функция использует глобальные изменяемые структуры данных, это может повлиять на распараллеливание. Например, допустим, у вас есть Memoize функция. Очевидно, весь смысл этого заключается в том, чтобы поддерживать какое-то глобальное состояние (хотя «глобальное» в том смысле, что оно не является локальным для вызова функции, оно все же «частное» в том смысле, что оно недоступно вне функции), чтобы ему не нужно запускать функцию несколько раз с одними и теми же аргументами, но при этом он остается чистым, потому что одни и те же входные данные всегда будут давать одни и те же выходные данные. Если ваша структура данных кеша является потокобезопасной (например, ConcurrentDictionary), вы все равно можете запускать свою функцию параллельно с самой собой. Если нет, то вы можете возразить, что функция не является чистой, потому что у нее есть побочные эффекты, которые наблюдаются при одновременном запуске.

Я должен добавить, что это распространенный метод в F #: начать с чисто функциональной процедуры, а затем оптимизировать ее, воспользовавшись изменяемым состоянием (например, кешированием, явным циклом), когда профилирование показывает, что оно слишком медленное.

Такой же подход можно найти в Clojure. Неизменяемые структуры данных в Clojure - список, карта и вектор - имеют свои «временные» аналоги, которые можно изменять. Ссылка Clojure на переходный процесс побуждает использовать их только в коде, который не может быть увиден "любым другим кодом".

В клиентском коде есть средства защиты от утечки переходных процессов:

• Обычные функции, которые работают с неизменяемыми структурами данных, не работают с переходными процессами. Их вызов вызовет исключение.

• Переходные процессы привязаны к потоку, в котором они созданы. Их изменение из любого другого потока вызовет исключение.

Сам код clojure.core использует множество негласных переходных процессов.

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

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

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

Я заметил, что некоторые хорошие программисты на F # (в Интернете и в книгах), похоже, очень спокойно относятся к использованию императивных методов для циклов. Похоже, они предпочитают простой цикл с изменяемыми переменными цикла сложной рекурсивной функции.

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

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

Я бы ответил на это вопросом: «Вы пишете функцию или используете ее?»

Есть 2 аспекта функций, пользователей и разработчиков.

Как пользователя, никто не заботится о внутренней структуре функции. Он может быть закодирован в байтовом коде и использовать жесткие побочные эффекты внутри с настоящего момента до дня суда, если он соответствует контракту входных-> исходящих данных, который можно было бы ожидать. Функция - это черный ящик или оракул, ее внутренняя структура не имеет значения (при условии, что она не делает ничего глупого и внешнего).

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

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

В чем преимущества неизменяемости перед изменяемыми структурами - это другой вопрос.