Побочные эффекты, возможные в чистом функциональном программировании

Haskell is a pure functional programming language. In Haskell all functions are pure (i.e. they always give the same output for the same inputs). But how do you handle side-effects in Haskell? Well, this problem is beautifully solved through the use of monads.

Taking I/O as an example. In Haskell every function that does I/O returns an IO computation, i.e. a computation in the IO monad. So, for instance, a function that reads an int from the keyboard, instead of returning an int, returns an IO computation that yields an int when it is run:

askForInt :: String -> IO Int

Because it returns an I/O computation instead of an Int, you cannot use this result directly in a sum, for example. In order to access the Int value you need to "unwrap" the computation. The only way to do this is to use the bind function (>>=):

(>>=) :: IO a -> (a -> IO b) -> IO b

Because this also returns an IO computation, you always end up with an I/O computation. This is how Haskell isolates side-effects. The IO monad acts as an abstraction of the state of the real world (in fact under the covers it is usually implemented with a type named RealWorld for the state part).

Functional Programming is about limiting & isolating side-effects, not trying to get entirely rid of them... because you can't.

... and yes I find FP useful (certainly with Erlang anyways): I find it is easier to get from "idea" to "program" (or problem to solution ;)... but of course that could just be me.

You need to know at least another essential concept: Monads. You will need this to do I/O and the other "useful" stuff!

Interacting with a user and communicating with a remote service do require some sort of non-functional part to your software.

Many "functional languages", (like most Lisps) are not purely functional. They still let you do things with side-effects, though side-effecty things are "discouraged" in most contexts.

Haskell is "purely functional" but still lets you do non-functional things via the IO monad. The basic idea is that your purely functional program emits a lazy data structure which is evaluated by a non-functional program (which you don't write, it's part of the environment). One could argue that this data structure itself is an imperative program. So you're sort of doing imperative meta-programming in a functional language.

Ignoring which approach is "better", the goal in both cases is to create a separation between the functional and non-functional parts of your programs, and to limit the size of the non-functional parts as much as possible. The functional parts tend to be more reusable, testable, and easier to reason about.

The way Haskell does it is by using monads see wikipedia and the explanation by Haskell on their page.

Basically the idea is that you do not get rid of the IO monad. My understanding is that you are able to chain functions that unwrap an IO monad and execute that function. But you are not able to remove the IO monad altogether.

Another example using monads that is not directly tied to IO is the Maybe Monad. This monad is 'unwrappable' in contrary to the IO monad. But it is easier to explain the use of monads using the Maybe monad. Let's assume you have the following function.

wrap :: Maybe x -> (x -> y) -> Maybe y
wrap Nothing  f = Nothing
wrap (Just x) f = Just (f x)

now you can call wrap (Just 4) (5+) which will return Just 9.

The idea of the IO-monad is that you can use functions like (+5) on the internal type. The monad will assure that the functions will be called in serial, because every function is chained with the wrapping IO-monad.

Единственный полностью чистый функциональный язык, о котором я знаю, - это система шаблонов в C ++. Haskell занимает второе место, делая явными императивные части программы.

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

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

И это помогло мне лучше писать таблицы стилей XSL.

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

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

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

Haskell идет в дальнейшем. Каждая часть программы Haskell чиста (по крайней мере, в отсутствие таких ошибок, как "unsafePerformIO"). Все функции, которые вы пишете на Haskell, являются чистыми.

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

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

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