Чи вважаються закриття з побічними ефектами "функціональним стилем"?

Багато сучасних мов програмування підтримують деяку концепцію закриття , тобто фрагмент коду (блок або функцію), який

1. Може трактуватися як значення, і тому зберігається у змінній, передається навколо різних частин коду, визначається в одній частині програми та викликається у зовсім іншій частині тієї ж програми.
2. Може захоплювати змінні з контексту, в якому він визначений, і отримувати доступ до них, коли пізніше викликається (можливо, в абсолютно іншому контексті).

Ось приклад закриття, написаного в Scala:

def filterList(xs: List[Int], lowerBound: Int): List[Int] =
  xs.filter(x => x >= lowerBound)

Літерал функції x => x >= lowerBoundмістить вільну змінну lowerBound, яка закрита (пов'язана) аргументом функції, filterListщо має те саме ім'я. Закриття передається методу бібліотеки filter, який може повторно викликати його як звичайну функцію.

Я читав багато питань і відповідей на цьому веб-сайті, і, наскільки я розумію, термін закриття часто автоматично асоціюється з функціональним програмуванням та стилем функціонального програмування.

Визначення функціонального програмування у вікіпедії звучить:

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

і далі

[...] у функціональному коді вихідне значення функції залежить лише від аргументів, які вводяться у функцію [...]. Усунення побічних ефектів може значно полегшити розуміння та прогнозування поведінки програми, що є однією з ключових мотивацій розвитку функціонального програмування.

З іншого боку, багато конструкцій закриття, що надаються мовами програмування, дозволяють закриттю захоплювати не локальні змінні та змінювати їх, коли викликається закриття, тим самим створюючи побічний ефект на середовище, в якому вони були визначені.

У цьому випадку закриття реалізують першу ідею функціонального програмування (функції - це першокласні об'єкти, які можна переміщувати, як і інші значення), але нехтують другою ідеєю (уникаючи побічних ефектів).

Чи вважається це використання закриттів із побічними ефектами функціональним стилем або це закриття вважається більш загальною конструкцією, яка може бути використана як для функціонального, так і нефункціонального стилю програмування? Чи є література на цю тему?

ВАЖЛИВА ПРИМІТКА

Я не сумніваюся у корисності побічних ефектів або у закритті побічних ефектів. Також мене не цікавить дискусія про переваги / недоліки закриттів із побічними ефектами чи без них.

Мені цікаво лише знати, чи використання таких закривань прихильником функціонального програмування все ще вважається функціональним стилем, або, навпаки, їх використання не рекомендується використовувати при використанні функціонального стилю.

Ні; визначення функціональної парадигми - це відсутність стану та неявна відсутність побічних ефектів. Мова не йде про функції високого порядку, закриття, маніпулювання списком, що підтримується мовою, чи інші мовні функції ...

Назва функціонального програмування походить від математичного поняття функцій - повторні виклики на одному вході завжди дають однаковий вихід - нульоподібну функцію. Цього можна досягти лише за умови незмінності даних . Щоб полегшити розвиток, функції стали змінними (функції змінюються, дані залишаються незмінними), і, таким чином, поняття функцій вищого порядку (функціонали в математиці, як похідні, наприклад) - функція, яка приймає як вхід іншу функцію. Для можливості функцій, які можна переносити і передавати як аргументи, були прийняті першокласні функції ; слідуючи цим, для подальшого підвищення продуктивності з'явилися закриття .

Це, звичайно, дуже спрощений погляд.

Ні. "Функціональний стиль" передбачає програмування без побічних ефектів.

Щоб зрозуміти, чому, подивіться запис у блозі Еріка Ліпперта про ForEach<T>метод розширення, і чому Microsoft не включив такий метод послідовності, як він у Linq :

Я по-філософськи проти такого способу із двох причин.

Перша причина полягає в тому, що це порушує принципи функціонального програмування, на яких ґрунтуються всі інші оператори послідовності. Очевидно, що єдиною метою заклику до цього методу є створення побічних ефектів. Мета виразу - обчислити значення, а не викликати побічний ефект. Мета твердження - викликати побічний ефект. Сайт виклику цієї речі виглядав би дуже жахливо як вираз (хоча, правда, оскільки метод повертає нікчемність, вираз можна використовувати лише в контексті "виразу висловлювання"). Це не відповідає мені, щоб зробити єдиного оператора послідовності, який корисний лише для його побічних ефектів.

Друга причина полягає в тому, що це додає мові нової нової репрезентативної сили. Це дозволяє переписати цей ідеально чистий код:

foreach(Foo foo in foos){ statement involving foo; }

в цей код:

foos.ForEach((Foo foo)=>{ statement involving foo; });

який використовує майже однакові символи в дещо іншому порядку. І все ж другу версію важче зрозуміти, важче налагодити і ввести семантику закриття, тим самим потенційно змінюючи життя предмета тонко.

Функціональне програмування напевно переносить функції першого класу на наступний концептуальний рівень, але оголошення анонімних функцій або передача функцій іншим функціям не обов'язково є функціональним програмуванням. У C все було цілим числом. Число, вказівник на дані, вказівник на функцію ... все лише вставки. Ви можете передати покажчики функцій іншим функціям, скласти списки покажчиків функцій ... Гек, якщо ви працюєте мовою складання, функції насправді є лише адресами в пам'яті, де зберігаються блоки машинних інструкцій. Надання функції імені є додатковими накладними витратами для людей, яким потрібен компілятор, щоб написати код. Тож функції були "першокласними" в цьому сенсі абсолютно не функціональною мовою.

Якщо єдине, що ви робите, - це обчислити математичні формули в REPL, то ви можете бути функціонально чистими своєю мовою. Але більшість бізнес-програмувань має побічні ефекти. Втрата грошей під час очікування завершення тривалої програми є побічним ефектом. Вживання будь-яких зовнішніх дій: запис у файл, оновлення бази даних, реєстрація подій у порядку тощо, вимагає зміни стану. Ми можемо обговорити, чи дійсно змінено стан, якщо ви вкладете ці дії в незмінні обгортки, які відштовхують побічні ефекти, щоб ваш код не переживав про них. Але це як би обговорювати, чи дерево видає шум, якщо воно падає в ліс, і нікого там не чути. Справа в тому, що дерево почало вертикально і опинилося на землі. Держава змінюється, коли речі закінчуються, навіть якщо лише повідомляти про те, що зроблено.

Тож нам залишається шкала функціональної чистоти, не чорно-біла, а відтінки сірого. І в такому масштабі, чим менше побічних ефектів, тим менша мінливість, тим краще (більш функціональна).

Якщо ви абсолютно потребуєте побічного ефекту або стану, що змінюється, у вашому функціональному коді інакше, ви прагнете інкапсулювати його з іншої частини програми якнайкраще. Використання замикання (або будь-чого іншого) для введення побічних ефектів або змінного стану в інакше чисті функції є антитезою функціонального програмування. Винятком може бути, якби закриття було найефективнішим способом інкапсуляції побічних ефектів від коду, якому він передається. Це все ще не "функціональне програмування", але це може бути шафа, яку ви можете отримати в певних ситуаціях.