Здравствуйте, m e, Вы писали:
_>>>О, кстати, вспомнил ещё про yield в Питоне — тоже интересное решение для ленивости, в императивном стиле можно сказать. )))
V>>Ну что уж поделать, коли генераторы через классы офигеешь писать.
ME>интересует конкретный пример генератора, который неудобно пишется
Здравствуйте, m e, Вы писали:
V>>Поинт в том, что в Хаскеле даже монада IO, которая кажется нечистой, также является чистой ф-ей. Просто у нее аргумент необычный ), но формально она чистая.
ME>более интересно то, почему в ghc внезапно стали писать библиотеку, где IO a = IO (State# RealWorld -> (#State# RealWorld, a#)) ?
(# #) -- unboxed tuple, оптимизация
State# встроенный полиморфный тип для IO/ST монад (может еще для чего). Тоже видимо для оптимизаций используется
ME>раньше вроде бы всем говорили "ребята, работа с RealWorld это удобное объяснение для начинающих, а на самом деле все сделано на continuations", и вот внезапно решили сделать монаду как в объяснении для начинающих? что случилось?
Кто говорил? Какие еще continuations? Причем тут начинающие?
Здравствуйте, m e, Вы писали:
V>>Если компилятор не бьет по рукам, то считай никакого ограничения нет.
ME>неправильно
ME>почти правильно вот так:
ME>Если компилятор не бьет по рукам, когда мы его об этом попросили, то считай никакого ограничения нет.
Здравствуйте, alex_public, Вы писали: _> А есть не контролирующие чистоту, но позволяющие все остальные функциональные техники — тот же Питон.
Таки не все — например сопоставление с образцом в нём не доступно, соответственно затруднено применение алгебраических типов данных...
Здравствуйте, alex_public, Вы писали: _>Генераторы это [ f x | x <- xs ] _>В Питоне записываем как что-то типа [f(x) for x in xs] _>Ну и дальше там есть аналоги буквальные на guards и так далее.
В python-е нет прямого аналога ленивых списков haskell.
То, что ты написал — это списковое дополнение для генерации списка. Т. е. после выполнения это будет обычный список все значения в котором уже вычислены.
Вот если заменить скобки с квадратных на круглые, получишь объект итератора.
Генераторы python реализуют только одну сторону ленивости: значение генерится только тогда, когда его потребовали.
Но как только генератор сгенерировал значение, он его забывает и нет возможности запросить его повторно.
Чтобы понять, в чём проблема, попробуй реализовать простое слияние принимающее 2 итератора и отдающее итератор выходной последовательности.
merge x [] = x
merge [] y = y
merge xxs@(x:xs) yys@(y:ys)
| x < y = x : merge xs yys
| x > y = y : merge xxs ys
| otherwise = x : y : merge xs ys
Или попробуй написать синтаксический разбор на итераторах.
Так же код может себя по разному вести в зависимости от конкретного типа итератора. И много других интересностей и разностей...
Так что итератор/генератор python-а изрядно низкоуровневая конструкция по сравнению со списками haskell.
Ну а сами выражения списковых дополнений — это всего лишь синтаксический сахар. И он да, почти полностью совпадает по выразительности.
Здравствуйте, MigMit, Вы писали: MM>Нет, это особенность РАБОТЫ. MM>Я как-то приводил пример: http://migmit.livejournal.com/32688.html MM>В языках с настоящим ПП — работает (и должно). MM>В языках с макросистемой, т.е., в плюсах — не работает (и не может).
Ты так и не определил, чем отличается макросистема от ПП.
В плюсах статический параметрический полиморфизм. Инстансирование шаблона может проходить только на этапе компиляции.
Это и демонстрирует твой пример.
Причём его можно существенно упростить. Код ниже не скомпилируется точно по той же причине:
#include <iostream>
template <int N> struct Test {};
int main() {
std::cout << "Enter a number: ";
int val;
std::cin >> val;
Test<val> t;
}
Естественно, в Java и C# этого требования нету — и код работает.
Здравствуйте, vshabanov, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>Отлично. Исходная точка найдена. Теперь надо выяснить, имеет ли способ ограничения повторного использования мира к определению чистоты. Имеет ли значение, как ограничивается повторное использование, будь это возможность компилятора, библиотеки, или честное слово в документации?
S>>Рад, еще одна точка понимания. Дальше ход такой: имеет ли значение, как называется тип мира? Метафора, конечно важна. Но чисто формально наш мир мог бы называться Dummy, Foo, или Foo9278345987. И чисто формально уже не важно, какую связь с миром имеет этот параметр. Важно лишь то, что каким-то образом ограничена возможность повторного использования экземпляра.
V>Эмм, как называется тип вообще не имеет значения.
V>Мне что-то кажется, что ты никак не можешь отделить программу от ее выполнения. Вот смотри, возьмем мы какой-нить sin x. Чистая ф-ия. Но при ее вычислении процессор выполняет инструкции, грязно меняющие содержимое памяти, счетчик команд, кеши. Программа может прочесть что-нить из файла (если x получен из getContents, или из какого-нить memory mapped file-а), что-нить может отсвопиться, отвалиться по out of memory. Ну и проц может сгореть, в конце концов.
V>Т.е. даже sin, при сильном влезании в детали, очень нечистая ф-ия. Но все-таки, мы считаем ее чистой.
Мы не считаем синус чистой функцией потому что она синус. Мы считаем ее чистой по выполнению формальных условий чистоты:
1) детерминированность. Будь функция хоть трижди синус, но если ее результат будет зависеть не только от аргумента, мы не сможем считать ее чистой. Ее результат так же не должен зависеть от внешнего взаимодействия с I/O девайсами. Это условие детерминированности придумал не я.
2) отсутствие семантически обозримых побочных эффектов и вывода через девайсы I/O.
То что нагревается процессор, грязно меняет счетчик команд, кэши, кочегар толкающий уголь в печь — это не является семантически обозримыми побочными эффектами, а так же вводом/выводом через I/O. Хотя я допускаю возможность построения таких систем, где нагревание процессора и т.п. будет семантически заметным. Но, т.к. я не знаю таких систем, не вижу повода заострять на этом внимание.
V>Также и с IO. В хаскелле нет нечистых ф-ий: не встроены в него переменные и взаимодействие с внешним миром. Однако работать с внешним миром все-таки надо. Чтобы не ломать чистоту стали считать мир обычным значением.
Выше ты со мной согласился, что в отношении ввода-вывода хаскель чистый уже потому, что не дает средств (за исключением бэкдоров) для прямого вызова взаимодействия с I/O. Поэтому я не вижу ни малейшего повода для ослабления формальных критериев чистой функции по причине "что бы не ломать чистоту".
Даже считая действия нечистыми, хаскель чист, т.к. позволяет лишь комбинировать их, но не выполнять. Так ради чего ломать критерий чистоты?
Я написал одно и то же дважды разными словами в надежде что мою мысль будет проще понять.
V>Получается что какая-нить readLine :: World -> (String, World) обычная чистая хаскельная ф-ия, ведь она берет String не откуда-то а из аргумента.
Она не чиста по определению. Нет повода считать что String берется откуда-то из экземпляра мира. V>Т.е. глядя на тип такой ф-ии никак нельзя понять, что она не чистая (да и нет в хаскеле нечистых ф-ий).
По ее сигнатуре мы действительно не можем утверждать что она не является чистой. Но по сути процессов, происходящих при ее выполнении — вполне можем утверждать что она не чистая.
V>Однако, в реальных программах тип World -- это все-таки не список строк stdin-а и stdout-а (хотя мог бы им быть в простых программах), а настоящий мир. А с реальным миром работать как с обычным хаскельным значением не получится. Мы не можем наплодить кучу миров и не можем использовать один и тот же мир дважды. Т.е. чтобы, при сохранении формальной чистоты, работать с реальным миром, а не заглушкой, необходимо, чтобы в любой момент времени в программе существовало только одно значение мира (тогда оно может меняться внутри, но программа этого все равно не заметит). Вот для того, чтобы значение было только одно, к нему не дают прямого доступа, только через bind/return/main.
Никакого отношения формальная чистота не имеет к возможности создания экземпляров более одного. Возможность меняться внутри — это не про хаскель, на сколько мне известно. А отсутствие прямого доступа к миру я могу объяснить более жизненными причинами чем мнимая чистота: невозможность прямого выполнения действия; обеспечение последовательности выполнения действий с побочными эффектами. Мир здесь играет роль лишь эстафетной палочки.
Давай предположим, что я согласился с тобой в вопросе чистоты действий. Тогда встает вопрос о том, почему хаскель запрещает (кроме бэкдоров) прямое выполнение действий? Они ведь "чистые", значит ничего испортить не могут и повлиять ни на что не должны!!! В чем тогда смысл?
V>Т.е. формально хаскелл полностью чистый язык. То, что writeFile что-то пишет на диск, программу на хаскеле не волнует никаким образом, для нее writeFile -- чистая ф-ия, преобразующая значение типа World. И, если ей подсунуть еще раз тот же мир (мысленно перенесясь назад во времени, например), то она выдаст тот же результат.
Это не так. writeFile не пишет на диск, не принимает World. writeFile чиста не потому что выдает тот же результат, приняв мир, а потому что ее результат никак в мире не отражается.
S>>Согласен, формально это уже impure. Но, при стечении хороших обстоятельств, при правильном использовании, мы избежим кодов возврата, исключений и т.п. Тогда сможем говорить о некой относительной чистоте. Но на самом деле мы говорим о нечистоте вывода. Т.е. я убежден в том, что никакие средства, в том числе изменения компилятора, не позволят сделать ввод/вывод или взаимодействие с внешним миром относительно самой программы чистым.
V>Я выше попытался в очередной раз объяснить, как это возможно
Ты объяснил только то, что пользуешься искаженным определением чистоты. А я выше попытался в очередной раз объяснить почему хаскель не нуждается в искажении чистоты.
S>>Итого, uniqueness typing это лишь один из способов гарантировать невозможность повторного использования экземпляра с приятной особенностью, позволяющей делать замену по месту. Никакой чистоты при взаимодействии с внешним миром оно не обеспечивает.
V>А реальный мир постоянно меняется, вне зависимости от выполнения программы и мы можем спокойно "заменять по месту" значения мира на текущее
К счастью, та затычка не нуждается в какой-либо синхронизации с миром. Даже думать о ней как о затычке мира вредно. Это лишь способ организации последовательности выполнения грязных действий.
Кстати, если ты считаешь действия чистыми, то для чего нужно организовывать порядок их выполнения?
Здравствуйте, samius, Вы писали:
V>>Также и с IO. В хаскелле нет нечистых ф-ий: не встроены в него переменные и взаимодействие с внешним миром. Однако работать с внешним миром все-таки надо. Чтобы не ломать чистоту стали считать мир обычным значением. S>Выше ты со мной согласился, что в отношении ввода-вывода хаскель чистый уже потому, что не дает средств (за исключением бэкдоров) для прямого вызова взаимодействия с I/O. Поэтому я не вижу ни малейшего повода для ослабления формальных критериев чистой функции по причине "что бы не ломать чистоту".
Какое такое ослабление критериев? Как раз наоборот, ничего не ослабляли. Вставили IO сохранив чистоту.
S>Даже считая действия нечистыми, хаскель чист, т.к. позволяет лишь комбинировать их, но не выполнять. Так ради чего ломать критерий чистоты? S>Я написал одно и то же дважды разными словами в надежде что мою мысль будет проще понять.
Ну я уже раз 5 написал, если не больше )
V>>Получается что какая-нить readLine :: World -> (String, World) обычная чистая хаскельная ф-ия, ведь она берет String не откуда-то а из аргумента. S>Она не чиста по определению. Нет повода считать что String берется откуда-то из экземпляра мира.
Да почему же не чиста? Для одного и того же мира вернет одну и ту же строку и один и тот же измененный мир. Побочных эффектов нет.
V>>Т.е. глядя на тип такой ф-ии никак нельзя понять, что она не чистая (да и нет в хаскеле нечистых ф-ий). S>По ее сигнатуре мы действительно не можем утверждать что она не является чистой. Но по сути процессов, происходящих при ее выполнении — вполне можем утверждать что она не чистая.
Каких таких процессов? Она меняет мир, а мир у нее является аргументом и результатом. Все чисто.
V>>Однако, в реальных программах тип World -- это все-таки не список строк stdin-а и stdout-а (хотя мог бы им быть в простых программах), а настоящий мир. А с реальным миром работать как с обычным хаскельным значением не получится. Мы не можем наплодить кучу миров и не можем использовать один и тот же мир дважды. Т.е. чтобы, при сохранении формальной чистоты, работать с реальным миром, а не заглушкой, необходимо, чтобы в любой момент времени в программе существовало только одно значение мира (тогда оно может меняться внутри, но программа этого все равно не заметит). Вот для того, чтобы значение было только одно, к нему не дают прямого доступа, только через bind/return/main. S>Никакого отношения формальная чистота не имеет к возможности создания экземпляров более одного. Возможность меняться внутри — это не про хаскель, на сколько мне известно. А отсутствие прямого доступа к миру я могу объяснить более жизненными причинами чем мнимая чистота: невозможность прямого выполнения действия; обеспечение последовательности выполнения действий с побочными эффектами. Мир здесь играет роль лишь эстафетной палочки.
S>Давай предположим, что я согласился с тобой в вопросе чистоты действий. Тогда встает вопрос о том, почему хаскель запрещает (кроме бэкдоров) прямое выполнение действий? Они ведь "чистые", значит ничего испортить не могут и повлиять ни на что не должны!!! В чем тогда смысл?
Потому что они чистые пока у нас только один используемый экземпляр мира в программе. При прямой работе можно запросто наплодить этих миров или вызывать ту же getLine несколько раз на одном и том же мире.
V>>Т.е. формально хаскелл полностью чистый язык. То, что writeFile что-то пишет на диск, программу на хаскеле не волнует никаким образом, для нее writeFile -- чистая ф-ия, преобразующая значение типа World. И, если ей подсунуть еще раз тот же мир (мысленно перенесясь назад во времени, например), то она выдаст тот же результат. S>Это не так. writeFile не пишет на диск, не принимает World. writeFile чиста не потому что выдает тот же результат, приняв мир, а потому что ее результат никак в мире не отражается.
А появившийся в мире файл -- это не результат?
S>>>Согласен, формально это уже impure. Но, при стечении хороших обстоятельств, при правильном использовании, мы избежим кодов возврата, исключений и т.п. Тогда сможем говорить о некой относительной чистоте. Но на самом деле мы говорим о нечистоте вывода. Т.е. я убежден в том, что никакие средства, в том числе изменения компилятора, не позволят сделать ввод/вывод или взаимодействие с внешним миром относительно самой программы чистым.
V>>Я выше попытался в очередной раз объяснить, как это возможно S>Ты объяснил только то, что пользуешься искаженным определением чистоты. А я выше попытался в очередной раз объяснить почему хаскель не нуждается в искажении чистоты.
И где же мое понятие чистоты искажено? Все строго по определению, ф-ии детерминированы (один и тот же результат на одном и том же World) и не имеют побочных эффектов (они в World).
S>>>Итого, uniqueness typing это лишь один из способов гарантировать невозможность повторного использования экземпляра с приятной особенностью, позволяющей делать замену по месту. Никакой чистоты при взаимодействии с внешним миром оно не обеспечивает.
V>>А реальный мир постоянно меняется, вне зависимости от выполнения программы и мы можем спокойно "заменять по месту" значения мира на текущее S>К счастью, та затычка не нуждается в какой-либо синхронизации с миром. Даже думать о ней как о затычке мира вредно. Это лишь способ организации последовательности выполнения грязных действий. S>Кстати, если ты считаешь действия чистыми, то для чего нужно организовывать порядок их выполнения?
Возьмем какой-нить sin x^2. Здесь важно сначала квадрат, потом синус, а не наоборот.
Здравствуйте, vshabanov, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>Выше ты со мной согласился, что в отношении ввода-вывода хаскель чистый уже потому, что не дает средств (за исключением бэкдоров) для прямого вызова взаимодействия с I/O. Поэтому я не вижу ни малейшего повода для ослабления формальных критериев чистой функции по причине "что бы не ломать чистоту".
V>Какое такое ослабление критериев? Как раз наоборот, ничего не ослабляли. Вставили IO сохранив чистоту.
а куда дели взаимодействие с I/O девайсами? Только не надо про World писать. Я же вижу побочные эффекты извне программы.
S>>Даже считая действия нечистыми, хаскель чист, т.к. позволяет лишь комбинировать их, но не выполнять. Так ради чего ломать критерий чистоты? S>>Я написал одно и то же дважды разными словами в надежде что мою мысль будет проще понять.
V>Ну я уже раз 5 написал, если не больше )
Ты как-то вроде соглашаешься, а потом гнешь свою линию. Причем я никаких комментариев по поводу моего понимания предмета не вижу. Ты просто продавливаешь что "один раз не считается" и что "побочные эффекты остаются в мире".
V>>>Получается что какая-нить readLine :: World -> (String, World) обычная чистая хаскельная ф-ия, ведь она берет String не откуда-то а из аргумента. S>>Она не чиста по определению. Нет повода считать что String берется откуда-то из экземпляра мира.
V>Да почему же не чиста? Для одного и того же мира вернет одну и ту же строку и один и тот же измененный мир. Побочных эффектов нет.
Она не чиста потому что читает строку извне программы. Она читает строку, которую я ввожу. Эта строка к World-у не имеет никакого отношения. Он ее угадать не мог.
S>>По ее сигнатуре мы действительно не можем утверждать что она не является чистой. Но по сути процессов, происходящих при ее выполнении — вполне можем утверждать что она не чистая.
V>Каких таких процессов? Она меняет мир, а мир у нее является аргументом и результатом. Все чисто.
Аргументом и результатом у нее не мир, а затычка. Изменения, кстати, отражаются вовне программы. А в затычке как раз не отражаются.
S>>Давай предположим, что я согласился с тобой в вопросе чистоты действий. Тогда встает вопрос о том, почему хаскель запрещает (кроме бэкдоров) прямое выполнение действий? Они ведь "чистые", значит ничего испортить не могут и повлиять ни на что не должны!!! В чем тогда смысл?
V>Потому что они чистые пока у нас только один используемый экземпляр мира в программе. При прямой работе можно запросто наплодить этих миров или вызывать ту же getLine несколько раз на одном и том же мире.
Они не чистые, даже учитывая единичность экземпляра. Портят окружающую среду.
S>>Это не так. writeFile не пишет на диск, не принимает World. writeFile чиста не потому что выдает тот же результат, приняв мир, а потому что ее результат никак в мире не отражается.
V>А появившийся в мире файл -- это не результат?
Нет. Прочитай пожалуйста внимательно следующее:
Появившийся в мире файл есть побочный эффект от выполнения действия IO (). writeFile не выполняла это действие. Она его построила. Таким образом, результатом writeFile является действие. При повторном вызове writeFile с теми же аргументами вернется точно такое же действие, при этом в мирах (в реальном и в World так же) ничего не изменится. В реальном — потому что действие не выполняли, а только построили. В World не изменится потому как writeFile его не принимает и с ним не работает. Я доступно изъясняюсь?
Как ты объясняешь появление файла на диске, учитывая "отсутствие" побочных эффектов у действия?
S>>Ты объяснил только то, что пользуешься искаженным определением чистоты. А я выше попытался в очередной раз объяснить почему хаскель не нуждается в искажении чистоты.
V>И где же мое понятие чистоты искажено? Все строго по определению, ф-ии детерминированы (один и тот же результат на одном и том же World) и не имеют побочных эффектов (они в World).
Побочные эффекты снаружи программы (в файловой системе, в консоли, в БД, и т.п.), а World является частью программы.
S>>К счастью, та затычка не нуждается в какой-либо синхронизации с миром. Даже думать о ней как о затычке мира вредно. Это лишь способ организации последовательности выполнения грязных действий. S>>Кстати, если ты считаешь действия чистыми, то для чего нужно организовывать порядок их выполнения?
V>Возьмем какой-нить sin x^2. Здесь важно сначала квадрат, потом синус, а не наоборот.
потому что композиция.
А в случае с миром и IO — я вообще не понимаю, зачем выполнять какие-то действия, если у них "нет побочных эффектов" и их результат никому не нужен?
Свои объяснения я прекрасно понимаю. У тебя — какие-то сказки про мир.
Здравствуйте, samius, Вы писали:
S>>>Выше ты со мной согласился, что в отношении ввода-вывода хаскель чистый уже потому, что не дает средств (за исключением бэкдоров) для прямого вызова взаимодействия с I/O. Поэтому я не вижу ни малейшего повода для ослабления формальных критериев чистой функции по причине "что бы не ломать чистоту".
V>>Какое такое ослабление критериев? Как раз наоборот, ничего не ослабляли. Вставили IO сохранив чистоту. S>а куда дели взаимодействие с I/O девайсами? Только не надо про World писать. Я же вижу побочные эффекты извне программы.
Ты может чего-то и видишь извне программы, а для программы всё это IO -- просто последовательность значений World, передаваемых между ф-иями.
Пока не могу придумать новых способов, как тебе это объяснить.
S>>>Даже считая действия нечистыми, хаскель чист, т.к. позволяет лишь комбинировать их, но не выполнять. Так ради чего ломать критерий чистоты? S>>>Я написал одно и то же дважды разными словами в надежде что мою мысль будет проще понять.
V>>Ну я уже раз 5 написал, если не больше ) S>Ты как-то вроде соглашаешься, а потом гнешь свою линию. Причем я никаких комментариев по поводу моего понимания предмета не вижу. Ты просто продавливаешь что "один раз не считается" и что "побочные эффекты остаются в мире".
Приходится "продавливать", т.к. ты постоянно пытаешься это опровергнуть.
V>>>>Получается что какая-нить readLine :: World -> (String, World) обычная чистая хаскельная ф-ия, ведь она берет String не откуда-то а из аргумента. S>>>Она не чиста по определению. Нет повода считать что String берется откуда-то из экземпляра мира.
V>>Да почему же не чиста? Для одного и того же мира вернет одну и ту же строку и один и тот же измененный мир. Побочных эффектов нет. S>Она не чиста потому что читает строку извне программы. Она читает строку, которую я ввожу. Эта строка к World-у не имеет никакого отношения. Он ее угадать не мог.
Эта строка имеет отношение к World, т.к. именно он в программе и моделирует реальный мир.
S>>>По ее сигнатуре мы действительно не можем утверждать что она не является чистой. Но по сути процессов, происходящих при ее выполнении — вполне можем утверждать что она не чистая.
V>>Каких таких процессов? Она меняет мир, а мир у нее является аргументом и результатом. Все чисто. S>Аргументом и результатом у нее не мир, а затычка. Изменения, кстати, отражаются вовне программы. А в затычке как раз не отражаются.
А программе то какое до этого дело? Для программы соблюдены все критерии чистоты, а то что World -- затычка, это уже неважно.
S>>>Давай предположим, что я согласился с тобой в вопросе чистоты действий. Тогда встает вопрос о том, почему хаскель запрещает (кроме бэкдоров) прямое выполнение действий? Они ведь "чистые", значит ничего испортить не могут и повлиять ни на что не должны!!! В чем тогда смысл?
V>>Потому что они чистые пока у нас только один используемый экземпляр мира в программе. При прямой работе можно запросто наплодить этих миров или вызывать ту же getLine несколько раз на одном и том же мире. S>Они не чистые, даже учитывая единичность экземпляра. Портят окружающую среду.
Да насрать на окружающую среду, для программы она не отличается от какого-нить Integer или Map. Обычное значение, ну с чуть ограниченным набором действий.
S>>>Это не так. writeFile не пишет на диск, не принимает World. writeFile чиста не потому что выдает тот же результат, приняв мир, а потому что ее результат никак в мире не отражается.
V>>А появившийся в мире файл -- это не результат? S>Нет. Прочитай пожалуйста внимательно следующее: S>Появившийся в мире файл есть побочный эффект от выполнения действия IO (). writeFile не выполняла это действие. Она его построила. Таким образом, результатом writeFile является действие. При повторном вызове writeFile с теми же аргументами вернется точно такое же действие, при этом в мирах (в реальном и в World так же) ничего не изменится. В реальном — потому что действие не выполняли, а только построили. В World не изменится потому как writeFile его не принимает и с ним не работает. Я доступно изъясняюсь?
Аа, в этом смысле да. writeFile ф-ия возвращающая действие. Но я говорю про внутренности этого действия.
S>Как ты объясняешь появление файла на диске, учитывая "отсутствие" побочных эффектов у действия?
Оно же меняет мир. Ты как-то никак не можешь понять, что если мир считать аргументом и результатом, то ф-ии становятся чистыми. Где у ф-ии побочный эффект -- во внешнем мире, а если этот мир является агрументом и результатом ф-ии?
S>>>Ты объяснил только то, что пользуешься искаженным определением чистоты. А я выше попытался в очередной раз объяснить почему хаскель не нуждается в искажении чистоты.
V>>И где же мое понятие чистоты искажено? Все строго по определению, ф-ии детерминированы (один и тот же результат на одном и том же World) и не имеют побочных эффектов (они в World). S>Побочные эффекты снаружи программы (в файловой системе, в консоли, в БД, и т.п.), а World является частью программы.
Тут взгяд идет от программы. Программа не знает о мире ничего
S>>>К счастью, та затычка не нуждается в какой-либо синхронизации с миром. Даже думать о ней как о затычке мира вредно. Это лишь способ организации последовательности выполнения грязных действий. S>>>Кстати, если ты считаешь действия чистыми, то для чего нужно организовывать порядок их выполнения?
V>>Возьмем какой-нить sin x^2. Здесь важно сначала квадрат, потом синус, а не наоборот. S>потому что композиция. S>А в случае с миром и IO — я вообще не понимаю, зачем выполнять какие-то действия, если у них "нет побочных эффектов" и их результат никому не нужен?
Как же не нужен, нам нужен измененный мир
S>Свои объяснения я прекрасно понимаю. У тебя — какие-то сказки про мир.
Здравствуйте, m e, Вы писали:
ME>именно поэтому я и употребляю словосочетание "более декларативен"
И вы, наверное, обладаете секретной техникой, которая позволяет вам упорядочивать языки по декларативности.
ME>если же ты не согласен, и настаиваешь на своем, самобытном определении слова "декларативность", то пожалуста выпиши это определение полностью
Я вовсе не настаиваю на "своем, самобытном" определении. Я пользуюсь общепринятым. Без ссылочной прозрачности определение декларативности станет чисто психологическим, т.е. будет характеризовать не объект классификации, а мозговые тараканы классификатора. Не знаю как вам — а мне до последних нет дела.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, m e, Вы писали:
ME>это неправильная аналогия
Аналогия правильная. Вам стало обидно, что C++ обижают и вы написали, что хотя и не знаете, будут ли проблемы с полиморфизмом в хаскеле-2010-с-расширениями (который называется просто хаскель), но думаете, что будут.
ME>правильная будет такой: пришел MigMit и стал всем продавать нетеряющиеся ложки
Нет. MigMit раньше исходил из ошибочного предположения, что в C++ есть параметрический полиморфизм. Но параметрический полиморфизм означает, что forall a. Box a описывает бесконечное кол-во типов. В C++ же кол-во типов всегда конечно, поэтому полиморфизм там только ad-hoc. Выяснив, как дела обстоят на самом деле, MigMit решил предостеречь остальных от следования предположению, которое на практике оказалось ошибочным.
ME>я продемонстрировал, как теряются серебрянные ложки, и отсюда вывел *правдоподобное* заключение, что и золотые тоже могут потеряться
Вы атаковали пример, проверяющий на наличие ПП в языке и иллюстрирующий проблему со стороны, не имеющей никакого отношения к ПП и иллюстрирующий проблемы с сабтайпингом и неразмеченными объединениями (вопросов нет — это настоящий заповедник грабель). В хаскеле неразмеченных объединений нет, а значит нет и такого направления для атаки, поэтому вы высосали из пальца наспекулировали несуществующую проблему.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, m e, Вы писали:
ME>там четко написано "Portability : non-portable (GHC Extensions)", значит ты должен был ответить "мы говорим не о хаскеле, а о GHC Extensions" и не путать меня и окружающих
Думаю, что окружающие в курсе, что "стандартный хаскель с расширениями" называется просто хаскель. А когда говорят о стандартном, всегда явно это указывают: haskell 98 или haskell 2010.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, vshabanov, Вы писали:
V>Здравствуйте, samius, Вы писали:
V>>>Какое такое ослабление критериев? Как раз наоборот, ничего не ослабляли. Вставили IO сохранив чистоту. S>>а куда дели взаимодействие с I/O девайсами? Только не надо про World писать. Я же вижу побочные эффекты извне программы.
V>Ты может чего-то и видишь извне программы, а для программы всё это IO -- просто последовательность значений World, передаваемых между ф-иями.
А как ты считаешь, программы на C видят побочные эффекты извне программы, или для них это просто последоватльность функций внутри программы?
V>Пока не могу придумать новых способов, как тебе это объяснить.
Не нужно новых способов. Я понимаю, что ты хочешь мне объяснить, просто в корне не согласен с этим.
В свою очередь ты вроде соглашаешься с тем что я объясняю, но все равно пытаешься мне объяснить то, с чем я не согласен.
S>>>>Даже считая действия нечистыми, хаскель чист, т.к. позволяет лишь комбинировать их, но не выполнять. Так ради чего ломать критерий чистоты? S>>>>Я написал одно и то же дважды разными словами в надежде что мою мысль будет проще понять.
S>>Ты как-то вроде соглашаешься, а потом гнешь свою линию. Причем я никаких комментариев по поводу моего понимания предмета не вижу. Ты просто продавливаешь что "один раз не считается" и что "побочные эффекты остаются в мире".
V>Приходится "продавливать", т.к. ты постоянно пытаешься это опровергнуть.
Я пытаюсь понять. Зачем нужно забивать на побочные эффекты вне программы что бы объяснить чистоту хаскеля, если ее можно объяснить с учетом наличия побочных эффектов?
S>>Она не чиста потому что читает строку извне программы. Она читает строку, которую я ввожу. Эта строка к World-у не имеет никакого отношения. Он ее угадать не мог.
V>Эта строка имеет отношение к World, т.к. именно он в программе и моделирует реальный мир.
Мы заходим на очередной круг. Вот что будет дальше: я скажу что World нифига не моделирует и не знает строку, которую я введу в консоль.
V>А программе то какое до этого дело? Для программы соблюдены все критерии чистоты, а то что World -- затычка, это уже неважно.
Для программы нарушаются критерии чистоты, потому как наблюдаются побочные эффекты извне программы.
S>>>>Давай предположим, что я согласился с тобой в вопросе чистоты действий. Тогда встает вопрос о том, почему хаскель запрещает (кроме бэкдоров) прямое выполнение действий? Они ведь "чистые", значит ничего испортить не могут и повлиять ни на что не должны!!! В чем тогда смысл?
V>Да насрать на окружающую среду, для программы она не отличается от какого-нить Integer или Map. Обычное значение, ну с чуть ограниченным набором действий.
Нет, не насрать, потому как определение чистоты не срет на окружающую среду.
S>>Появившийся в мире файл есть побочный эффект от выполнения действия IO ()....
V>Аа, в этом смысле да. writeFile ф-ия возвращающая действие. Но я говорю про внутренности этого действия.
Вот. Ты опять со мной согласился. Теперь вопрос (уже который раз). Зачем нужно считать это действие чистым? Хаскель вэ том не нуждается. Нечистота этого действия не бросает тень на чистоту хаскеля, т.к. выполнять действие мы "не можем". Так зачем нужно выдумывать что побочных эффектов от этого действия нет, если они остаются в файловой системе? Зачем выдумывать что изменения происходят лишь во внутреннем World программы и что программе чихать на их наличие во внешнем мире. Ведь есть определение чистой функции и там нет ничего про внутренний мир программы, но есть ввод/вывод в I/O и он считается прямым признаком грязи.
S>>Как ты объясняешь появление файла на диске, учитывая "отсутствие" побочных эффектов у действия?
V>Оно же меняет мир. Ты как-то никак не можешь понять, что если мир считать аргументом и результатом, то ф-ии становятся чистыми. Где у ф-ии побочный эффект -- во внешнем мире, а если этот мир является агрументом и результатом ф-ии?
Ты как-то никак не хочешь понять, что связи между внутренним миром World и внешним миром программы нет никакой. Ты хочешь убедить меня в том, что во внутреннем World происходят какие-то изменения, которые на самом деле происходят во внешнем мире и никак не связаны с внутренним World. Я уверен, что во внутреннем World нет никакой файловой системы, сетевых интерфейсов, консоли в конце концов
Мне кажется ты сам не должен верить в то что изменения внешнего мира как-то отражаются на внутреннем World. Дело даже не в этом. Я уже писал что World нужен как эстафетная палочка для прогонки по действиям с целью обеспечить порядок их выполнения. Порядок этот нужен для того, что бы побочные эффекты во внешнем мире легли в нужном порядке. Сам World при этом никаких изменений не претерпевает. Наверняка сказать не могу, я не добрался еще до этого. Но уверен на 120%.
S>>Побочные эффекты снаружи программы (в файловой системе, в консоли, в БД, и т.п.), а World является частью программы.
V>Тут взгяд идет от программы. Программа не знает о мире ничего.
А ей нужно что-то знать? Суть программы на хаскеле — построить действие. Действие само спросит у мира что ему надо и испортит его как сможет. Но это уже к программе на хаскеле отношения не имеет, т.к. main лишь возвращает действие, но не пытается его выполнить.
S>>А в случае с миром и IO — я вообще не понимаю, зачем выполнять какие-то действия, если у них "нет побочных эффектов" и их результат никому не нужен?
V>Как же не нужен, нам нужен измененный мир
Внутренний? Он не меняется. В нем нечему меняться. Меняется внешний мир. И его изменения — это побочный эффект выполнения действия.
S>>Свои объяснения я прекрасно понимаю. У тебя — какие-то сказки про мир. V>Жалко, что ты не понимаешь моих объяснений )
Я их понимаю, я их не могу принять.
Предлагаю взглянуть на определение pure function из википедии. Ты согласен с этим определением? Если нет, дай ссылку на то определение, с которым ты согласен.
Если согласен, то что ты подразумеваешь под external input from I/O devices и output to I/O devices соответственно? Только не надо опять про World, ведь в нем никаких девайсов нет.
Здравствуйте, samius, Вы писали:
S>Если согласен, то что ты подразумеваешь под external input from I/O devices и output to I/O devices соответственно? Только не надо опять про World, ведь в нем никаких девайсов нет.
А ты ответь, что понимаешь под semantically observable.
Здравствуйте, VoidEx, Вы писали:
VE>Здравствуйте, samius, Вы писали:
S>>Если согласен, то что ты подразумеваешь под external input from I/O devices и output to I/O devices соответственно? Только не надо опять про World, ведь в нем никаких девайсов нет.
VE>А ты ответь, что понимаешь под semantically observable.
Семантически обозримые эффекты — изменения, которые обнаружимы средствами языка. Типично для императивных языков — глобальные переменные, любые изменяемые состояния.
ME>>там четко написано "Portability : non-portable (GHC Extensions)", значит ты должен был ответить "мы говорим не о хаскеле, а о GHC Extensions" и не путать меня и окружающих
K>Думаю, что окружающие в курсе, что "стандартный хаскель с расширениями" называется просто хаскель. А когда говорят о стандартном, всегда явно это указывают: haskell 98 или haskell 2010.
очень, очень любопытно
так хаскелем у тебя называется хаскель с какими расширениями? с расширениями любого из почти 10 компиляторов? или только с расширениями ghс? если так, то какого хрена такая дискриминация?
K>Аналогия правильная. Вам стало обидно, что C++ обижают и вы написали, что хотя и не знаете, будут ли проблемы с полиморфизмом в хаскеле-2010-с-расширениями (который называется просто хаскель), но думаете, что будут.
с++ обижают не зря -- полностью проверяемого компилятором ПП там, действительно, похоже, нет (хотя можно легко сделать частично проверяемый)
*НО* при этом эмуляция зависимых типов параметрическим полиморфизмом -- это примерно как коленвал ДВС из дерева
K>Вы атаковали пример, проверяющий на наличие ПП в языке и иллюстрирующий проблему со стороны, не имеющей никакого отношения к ПП и иллюстрирующий проблемы с сабтайпингом и неразмеченными объединениями (вопросов нет — это настоящий заповедник грабель). В хаскеле неразмеченных объединений нет, а значит нет и такого направления для атаки, поэтому вы высосали из пальца наспекулировали несуществующую проблему.
зато там есть _|_
надо попробовать его использовать как вектор атаки
да и вообще -- есть можно сказать большое число векторов атаки, и хрен докажешь, что ПП че-то-там гарантирует, если есть расширения, которые не рассматривались специально на тему "а не сломаем ли мы вот это..."
