Является ли Haskell действительно чистым (является ли любой язык, который имеет дело с вводом и выводом вне системы)?

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

что значит рассуждать о компьютерных системах "вне доски математики"? Что это за рассуждения? Расплата?

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

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

vector<char> read(filepath_t)

в нашем новом "чистом стиле", Мы работаем так:

pair<vector<char>, world_t> read(world_t, filepath_t)

это на самом деле, как работает каждое действие Haskell IO.

Итак, теперь у нас есть чистая модель IO. слава Богу. Если бы мы не могли этого сделать, тогда, возможно, лямбда-исчисление и машины Тьюринга не являются эквивалентными формализмами, и тогда нам пришлось бы что-то объяснять. Мы еще не закончили, но две проблемы, оставленные нам, просты:

• что идет в world_t структура? Описание каждой песчинки, лезвия трава, разбитое сердце и золотой закат?

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

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

что касается запутывания миров, мы хотели бы скрыть мир, проходящий внутри библиотеки, чтобы не было возможности добраться до миров и, таким образом, нет способа смешать их. Оказывается, монады-отличный способ скрыть "боковой канал" в вычислении. Войти в монаду IO.

некоторое время назад такой вопрос, как ваш, был задан в списке рассылки Haskell, и там я вошел в "боковой канал" Более подробно. Вот поток Reddit (который ссылается на мою оригинальную электронную почту):

http://www.reddit.com/r/haskell/comments/8bhir/why_the_io_monad_isnt_a_dirty_hack/

Я очень новичок в функциональном программировании, но вот как я это понимаю:

в haskell вы определяете кучу функций. Эти функции не выполняются. Их могут оценить.

в частности, есть одна функция, которая оценивается. Это постоянная функция, которая производит набор "действий"."Действия включают в себя оценку функций и выполнение Ио и других "реальных" вещей. У вас могут быть функции, которые создают и передают эти действия и они никогда не будут выполняться, если функция не оценивается с помощью unsafePerformIO или они возвращаются основной функцией.

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

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

Я думаю об этом так: Программы должны делать что-то с внешним миром, чтобы быть полезными. То, что происходит (или должно происходить) при написании кода (на любом языке), заключается в том, что вы стремитесь написать как можно больше чистого, свободного от побочных эффектов кода и загнать IO в определенные места.

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

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

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

для расширенной версии sdcwc в виде конструкции IO, можно посмотреть на пакет IOSpec на Hackage:http://hackage.haskell.org/package/IOSpec

нет, это не так. Монада IO нечиста, потому что она имеет побочные эффекты и изменчивое состояние (условия гонки возможны в программах Haskell так ? а. .. чистый язык FP не знает что-то вроде "состояния расы"). Действительно чистый FP чист с типом уникальности, или вяз с FRP (функциональным реактивным программированием) не Haskell. Хаскелл - одна большая ложь.

доказательство :

import Control.Concurrent 
import System.IO as IO
import Data.IORef as IOR

import Control.Monad.STM
import Control.Concurrent.STM.TVar

limit = 150000
threadsCount = 50

-- Don't talk about purity in Haskell when we have race conditions 
-- in unlocked memory ... PURE language don't need LOCKING because
-- there isn't any mutable state or another side effects !!

main = do
    hSetBuffering stdout NoBuffering
    putStr "Lock counter? : "
    a <- getLine
    if a == "y" || a == "yes" || a == "Yes" || a == "Y"
    then withLocking
    else noLocking

noLocking = do
    counter <- newIORef 0
    let doWork = 
        mapM_ (\_ -> IOR.modifyIORef counter (\x -> x + 1)) [1..limit]
    threads <- mapM (\_ -> forkIO doWork) [1..threadsCount]
    -- Sorry, it's dirty but time is expensive ...
    threadDelay (15 * 1000 * 1000)
    val <- IOR.readIORef counter
    IO.putStrLn ("It may be " ++ show (threadsCount * limit) ++ 
        " but it is " ++ show val) 

withLocking = do
    counter <- atomically (newTVar 0)
    let doWork = 
        mapM_ (\_ -> atomically $ modifyTVar counter (\x -> 
            x + 1)) [1..limit]
    threads <- mapM (\_ -> forkIO doWork) [1..threadsCount]
    threadDelay (15 * 1000 * 1000)
    val <- atomically $ readTVar counter
    IO.putStrLn ("It may be " ++ show (threadsCount * limit) ++ 
        " but it is " ++ show val)