Здравствуйте, deniok, Вы писали:
D>Возможность доступа к внешнему для функции состоянию ликвидирует саму возможность говорить о доказуемых гарантиях ее чистоты.
"доказуемые гарантии чистоты" пусть идут в баню вместе с теоретиками. а нам простым индусам нужно быстро писать код.
D>А состояние с контролируемой локальностью вводится в чистом ФП запросто: D>
D>-- описывам вычисление над состоянием
D>-- (в do-нотации выглядело бы еще более императивно)
D>tick :: State Int Int
D>tick = get >>= \n -> put (n+1) >> return n
D>-- делаем вычисление (императивщина локальна внутри монады State)
D>plusOne :: Int -> Int
D>plusOne n = execState tick n
D>-- делаем вычисление несколько раз
D>plus :: Int -> Int -> Int
D>plus n x = execState (sequence $ replicate n tick) x
D>-- кстати, sequence $ replicate n tick :: State Int [Int]
D>-- то есть мы еще в монаде State
D>
Что я вижу? Обычный объект, инкапсулирующий состояние. Какое же это ФП? Тогда и java по-твоему функциональный язык?
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, LaPerouse, Вы писали:
DR>>>>В IDEA появилась поддержка Немерле? При чём он тут? C>>>Я говорил про IDE вообще. Всё перечисленное есть для Scala. LP>>Скорее нет чем есть. Плагин для Eclipse пока сырой и кривой. C>IDEA стала OpenSource. Кому теперь нужен Eclipse?
Очевидно тем, кто считает Eclipse более удобной и мощной средой чем IDEA.
Социализм — это власть трудящихся и централизованная плановая экономика.
LP>Что я вижу? Обычный объект, инкапсулирующий состояние.
Нет, это только видимость. Обычный объект — плохо определенное понятие, неявно апеллирующее к свойствам рантайма. Монада же State (как и большинство других) вводится чисто синтаксически.
LP>Какое же это ФП? Тогда и java по-твоему функциональный язык?
Нет, java не функциональный язык, она не сводится к лямбда-исчислению.
Здравствуйте, LaPerouse, Вы писали:
DR>>>>>В IDEA появилась поддержка Немерле? При чём он тут? C>>>>Я говорил про IDE вообще. Всё перечисленное есть для Scala. LP>>>Скорее нет чем есть. Плагин для Eclipse пока сырой и кривой. C>>IDEA стала OpenSource. Кому теперь нужен Eclipse? LP>Очевидно тем, кто считает Eclipse более удобной и мощной средой чем IDEA.
А, ну они заблуждаются.
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, lomeo, Вы писали:
L>>И я до сих пор не понимаю, как возможность выделить состояние в тип, позволив ограничивать работу с ним, позволив быть ему composable быть запутанным и менее модульным, чем состояние в ИП, размазанное по всей программе?
L>Извиняюсь, что написал не по-русски, но, думаю, вопрос понятен?
Вопрос понятен. Непонятно, чем ты руководствовался, задавая его Ведь ИП — он сильно разный бывает. Если для укрощения дикого состояния, которое похоже любителям хаскеля кажется средоточием вселенского зла, использовать ООП, то получим ровно то, о чем ты написал. Можно конечно сделать тоже самое с монадой State, но при чем тут спрашивается ФП?
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, LaPerouse, Вы писали:
DR>>>>>>В IDEA появилась поддержка Немерле? При чём он тут? C>>>>>Я говорил про IDE вообще. Всё перечисленное есть для Scala. LP>>>>Скорее нет чем есть. Плагин для Eclipse пока сырой и кривой. C>>>IDEA стала OpenSource. Кому теперь нужен Eclipse? LP>>Очевидно тем, кто считает Eclipse более удобной и мощной средой чем IDEA. C>А, ну они заблуждаются.
А я считаю что заблуждаются те, кто считают IDEA едва ли не вершиной совершенства. Да,редактор кода может получше будет, однако совокупная мощь платформы Eclipse задавит кого хочешь. Даже NetBeans. К тому же открыли только небольшую часть проекта.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, deniok, Вы писали:
D>Здравствуйте, LaPerouse, Вы писали:
LP>>Что я вижу? Обычный объект, инкапсулирующий состояние.
D>Нет, это только видимость. Обычный объект — плохо определенное понятие, неявно апеллирующее к свойствам рантайма. Монада же State (как и большинство других) вводится чисто синтаксически.
Если оно крякает как утка, плавает как утка и выглядит как утка, то это, вероятно, утка и есть.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
LP>Вопрос понятен. Непонятно, чем ты руководствовался, задавая его Ведь ИП — он сильно разный бывает. Если для укрощения дикого состояния, которое похоже любителям хаскеля кажется средоточием вселенского зла, использовать ООП, то получим ровно то, о чем ты написал. Можно конечно сделать тоже самое с монадой State, но при чем тут спрашивается ФП?
Я так понял, что монады, инкапсулирующие состояние, отличаются от императивного решения тем, что являются
1) запутанными
2) менее модульными, чем явное состояние
Оба эти пункта я взял из твоей цитаты, как раз то, что ты сам выделил. Затем я показал, что вижу гораздо бОльшую ясность и модульность в том, что мы можем не только делать ровно то же самое, но ещё и ограничивать использование и обращаться с состоянием как с first-class value. Именно об этой разнице в моём понимании и цитате я и спросил.
Сейчас же оказывается, что это одно и то же (выделенное). Т.е. монады состояния как минимум не хуже явного состояния. Следовательно, проблем с модульностью у ФП нет. Тогда к чему ты привёл эту цитату? Или монады — не ФП?
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, LaPerouse, Вы писали:
LP>>Вопрос понятен. Непонятно, чем ты руководствовался, задавая его Ведь ИП — он сильно разный бывает. Если для укрощения дикого состояния, которое похоже любителям хаскеля кажется средоточием вселенского зла, использовать ООП, то получим ровно то, о чем ты написал. Можно конечно сделать тоже самое с монадой State, но при чем тут спрашивается ФП?
L>Я так понял, что монады, инкапсулирующие состояние, отличаются от императивного решения тем, что являются
L>1) запутанными L>2) менее модульными, чем явное состояние
L>Оба эти пункта я взял из твоей цитаты, как раз то, что ты сам выделил. Затем я показал, что вижу гораздо бОльшую ясность и модульность в том, что мы можем не только делать ровно то же самое, но ещё и ограничивать использование и обращаться с состоянием как с first-class value. Именно об этой разнице в моём понимании и цитате я и спросил.
Я не понял. Состояние оно либо есть либо нет. С монадой State чистота функции нарушается? Нарушается. Все, ФП кончился. Началась суровая жизнь
L>Сейчас же оказывается, что это одно и то же (выделенное). Т.е. монады состояния как минимум не хуже явного состояния. Следовательно, проблем с модульностью у ФП нет. Тогда к чему ты привёл эту цитату? Или монады — не ФП?
Да, см. выделенное. Это не фп. Ну, и более запутанные тоже.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
C>>А, ну они заблуждаются. LP>А я считаю что заблуждаются те, кто считают IDEA едва ли не вершиной совершенства. Да,редактор кода может получше будет, однако совокупная мощь платформы Eclipse задавит кого хочешь.
Нет, это Eclipse — помойка несовместимых плугинов. До интегрированности IDEA ей как до Луны.
LP>Даже NetBeans.
LOL! Кому вообще нафиг NetBeans нужен, чтоб с ним сравнивать?
LP>К тому же открыли только небольшую часть проекта.
Достаточну для разработки на Scala.
Здравствуйте, LaPerouse, Вы писали:
LP>Я не понял. Состояние оно либо есть либо нет. С монадой State чистота функции нарушается? Нарушается. Все, ФП кончился. Началась суровая жизнь
В чём проблема состояния по твоему? Решает ли эту проблему монада State?
Здравствуйте, LaPerouse, Вы писали:
LP>Я не понял. Состояние оно либо есть либо нет. С монадой State чистота функции нарушается? Нарушается. Все, ФП кончился. Началась суровая жизнь
А, так ты даже этого не знаешь! Ты просто Хаскелл мало изучал. Открою тебе страшную тайну — с монадой State чистота функции не нарушается. Монада State — чисто синтаксическая конструкция, безо всякого тайного хакерства, чистая как слеза ребенка:
newtype State s a = State { runState :: s -> (a, s) }
instance Monad (State s) where
return a = State $ \s -> (a, s)
m >>= k = State $ \s -> let
(a, s') = runState m s
in runState (k a) s'
class (Monad m) => MonadState s m | m -> s where
get :: m s
put :: s -> m ()
instance MonadState s (State s) where
get = State $ \s -> (s, s)
put s = State $ \_ -> ((), s)
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, LaPerouse, Вы писали:
LP>>Я не понял. Состояние оно либо есть либо нет. С монадой State чистота функции нарушается? Нарушается. Все, ФП кончился. Началась суровая жизнь
L>В чём проблема состояния по твоему?
Знал я когда то, но уже забыл
В SICP написано на эту тему много. Да и в том же CTM должно быть (хотя я не читал эту книгу).
Основная проблема состояния — это его изменяемость и как следствие отсутствие прочной опоры под ногами. То есть сущность которая находится в одном состоянии в определенный момент времени может изменить состояние, при этом оставшись семантически той же самой сущностью. Поэтому возможны ошибки, когда другие сущности, зависящие от нее, перестают быть совместимыми с этим новым состоянием. В ФП вместо изменения какой то сущности предлагается пересоздать ее, одновременно пересоздав (если требуется) все другие сущности, которые от нее зависят. Тем самым решается проблема несовместимости, но привносятся новые проблемы. Одна из них — нарушение модульности. Смотри секцию 4.7 в CTM, там хорошо написано.
То есть нет серебряной пули. То, что прекрасно решает одни проблемы, порождает другие. Поэтому хорошо использовать мультипарадигменные языки, которые позволят использовать наиболее приемлемое для данной задачи решение.
L>Решает ли эту проблему монада State?
Да не знаю я. Я вижу, что на примерах оно ничем не отличается от объекта, функции перестают быть чистыми, то есть фп здесь и не пахнет. Это я твердо знаю. Как она устроена и как связана с основами мироздания — не ко мне вопрос.
Кстати, поясни пожалуйста, чем таки эта монада отличается от объекта (если отличается)
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, deniok, Вы писали:
D>Здравствуйте, LaPerouse, Вы писали:
LP>>Я не понял. Состояние оно либо есть либо нет. С монадой State чистота функции нарушается? Нарушается. Все, ФП кончился. Началась суровая жизнь
D>А, так ты даже этого не знаешь! Ты просто Хаскелл мало изучал. Открою тебе страшную тайну — с монадой State чистота функции не нарушается. Монада State — чисто синтаксическая конструкция, безо всякого тайного хакерства, чистая как слеза ребенка:
как же не нарушается, если я вижу, что нарушается?
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
LP>Основная проблема состояния — это его изменяемость и как следствие отсутствие прочной опоры под ногами. То есть сущность которая находится в одном состоянии в определенный момент времени может изменить состояние, при этом оставшись семантически той же самой сущностью. Поэтому возможны ошибки, когда другие сущности, зависящие от нее, перестают быть совместимыми с этим новым состоянием.
Верно. Из-за инкапсуляции состояния (труднодостижимой в ИП) мы не имеем этих связей. Все изменения состояния у нас локальны и отражаются только на хорошо известные участки кода. Связей с другими сущностями тоже нет, потому что снаружи этой монады у неё просто нет состояния — это всего лишь функция.
LP>В ФП вместо изменения какой то сущности предлагается пересоздать ее, одновременно пересоздав (если требуется) все другие сущности, которые от нее зависят. Тем самым решается проблема несовместимости, но привносятся новые проблемы. Одна из них — нарушение модульности. Смотри секцию 4.7 в CTM, там хорошо написано.
Я прочитал эту секцию. Нарушения модульности при использовании монады — нет. Был один интерфейс у функций (a -> M b), такой же и остался.
LP>То есть нет серебряной пули. То, что прекрасно решает одни проблемы, порождает другие. Поэтому хорошо использовать мультипарадигменные языки, которые позволят использовать наиболее приемлемое для данной задачи решение.
Так как этот вывод был основан на ложной предпосылке, предлагаю не считать его верным. Я писал на Схеме (сейчас реже) и пишу на Скала. Использовать мультипарадигменные языки — нехорошо Это мнение.
L>>Решает ли эту проблему монада State?
LP>Да не знаю я. Я вижу, что на примерах оно ничем не отличается от объекта, функции перестают быть чистыми, то есть фп здесь и не пахнет. Это я твердо знаю. Как она устроена и как связана с основами мироздания — не ко мне вопрос. LP>Кстати, поясни пожалуйста, чем таки эта монада отличается от объекта (если отличается)
Это всего лишь функция s -> (a,s). Кстати, чистая.
s у нас состояние, a — результат. Просто, будучи зашитой в монаду мы не видим s, а работаем с a напрямую:
counter <- get
let newCounter = counter + 1
put newCounter
Здравствуйте, LaPerouse, Вы писали: LP>То есть сущность которая находится в одном состоянии в определенный момент времени может изменить состояние, при этом оставшись семантически той же самой сущностью.
Очень похоже на один из сценариев использования stm. В мире фп как минимум в clojure и хаскеле все необходимые для этого средства уже есть. Один из этих языков даже чистый.
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, LaPerouse, Вы писали:
LP>>Основная проблема состояния — это его изменяемость и как следствие отсутствие прочной опоры под ногами. То есть сущность которая находится в одном состоянии в определенный момент времени может изменить состояние, при этом оставшись семантически той же самой сущностью. Поэтому возможны ошибки, когда другие сущности, зависящие от нее, перестают быть совместимыми с этим новым состоянием.
L>Верно. Из-за инкапсуляции состояния (труднодостижимой в ИП) мы не имеем этих связей. Все изменения состояния у нас локальны и отражаются только на хорошо известные участки кода. Связей с другими сущностями тоже нет, потому что снаружи этой монады у неё просто нет состояния — это всего лишь функция.
То есть получается, что это таки ИП, но ИП сильно контролируемый. Так сказать, попытка укрощения состояния номер два. Первым был ООП.
Нет?
И опять же, во многих руководствах по хаскелю говорится, что монады — это императивщина, и что сильно юзать их — грех. Чувствую, кто-то меня обманывает, осталось разобраться кто
LP>>В ФП вместо изменения какой то сущности предлагается пересоздать ее, одновременно пересоздав (если требуется) все другие сущности, которые от нее зависят. Тем самым решается проблема несовместимости, но привносятся новые проблемы. Одна из них — нарушение модульности. Смотри секцию 4.7 в CTM, там хорошо написано.
L>Я прочитал эту секцию. Нарушения модульности при использовании монады — нет. Был один интерфейс у функций (a -> M b), такой же и остался.
Ну значит монады какие-то не те. Автор ведь не уточняет, какие монады имеет ввиду.
И кстати он их там не использует, то есть описываемые в секции 4.7 проблемы касаются чистого безмонадического фп. Может быть монады, решая проблему кривого интерфейса в секции 4.7, привносят какую-то новую проблему. Например ту, о которой он говорит в приведенном мной куске вступления:
Monads are used to encode state by threading it throughout the program. This makes programs more intricate but does not achieve the modularity properties of true explicit state
(только вот секция 4.7 тут не при чем, возможно он хотел написать об этой проблеме когда писал вступление, но забыл)
L>Это всего лишь функция s -> (a,s). Кстати, чистая. L>s у нас состояние, a — результат. Просто, будучи зашитой в монаду мы не видим s, а работаем с a напрямую: L>
