Re[10]: Мифический Haskell - Декларативное программирование

Здравствуйте, vshabanov, Вы писали:

V>Здравствуйте, samius, Вы писали:

V>>>IO a = World -> (a, World)

S>>Чистая — значит детерминированная + без побочных эффектов. Если по поводу побочных эффектов можно филосовствовать (ну там что они появились в новом экземпляре World), то с детерминированностью тут точно проблемы.

V>Все вполне детерминировано. Просто World каждый раз разный. А если World одинаковый (мир, на момент запуска программы), то и результат всегда будет один.
Это значит что мы фиксируем мир, в котором я введу конкретную строку до того как "выполнилась" функция IO String, являющаяся результатом getLine? И в таком мире, в котором я ввожу лишь эту строку, считаем что функция-результат getLine детерминирована?
Я предпочитаю считать что в одном и том же мире я могу получить разный результат в IO a.

S>>Наоборот, main — чистая. чистая main строит нечистую функцию IO (). И эта нечистая функция-результат чистого main далее выполняется рантаймом. Я это себе так представляю.

V>И main чистая и IO (), которое она вычисляет, тоже чистое, а вот рантайм уже да, во всю оперирует с миром.

V>В целом граница достаточно тонкая и условная, важно понять, что концептуально IO -- обычная чистая ф-ия, просто она работает с миром.
Чистая — значит детерминированная уже сейчас.

V>Вполне можно сделать какой-нить специальный "мир" для запуска программы, который, например, для getLine всегда будет подставлять одни и те же строки. Тогда (если программа, кроме как через getLine, с миром никак не реагирует) результат поведения программы будет детерминированным.
Вот когда будет специальный "мир", тогда и будем считать результат IO a детерминированным. А до тех пор, пока мы подавая один и тот же экземпляр мира будем получать различные результаты — увы.

Здравствуйте, dsorokin, Вы писали:

D>Здравствуйте, alex_public, Вы писали:

_>>Эээ, Lisp — это тоже анти Хаскель? )))

D>Лиспы вполне себе функциональные. Просто тут возникает путаница. Хаскель является языком чистого функционального программирования. Но апологеты почему-то забывают об этой особенности и любят говорить за все функциональное программирование, чем вызывают немалое раздражение.

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

https://en.wikipedia.org/wiki/Functional_programming

In computer science, functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data.

Всё предельно чётко.

Здравствуйте, m e, Вы писали:

ME>каким образом IO a -- чистая ф-я?

Таким же, каким State Int a. Надеюсь то, что State Int a чистая, вопросов не вызывает?

Здравствуйте, vshabanov, Вы писали:

FR>>make не сборочная система?

V>Сборочная, но не стал бы называть один запускной файл системой.

Странный критерий для понятия "система".
По сложности разработки make и scons вполне сопоставимы.

FR>>Две строчки будут в make только для "hello world".

V>Равно как и в SCons.

Да, но в SCons для более сложных случаев строчек будет на порядок меньше.

FR>>Для кроссплатформенных или когда нужна многовариантная сборка scons или аналоги существенно проще чем маке.

V>Для больших C++ проектов, возможно. Для многих средних проектов make-а более чем достаточно.

Я когда активно использовал SCons применял как раз для небольших проектов, работы с ним было на порядок меньше
чем если бы использовал make.

Здравствуйте, samius, Вы писали:

S>Здравствуйте, vshabanov, Вы писали:

V>>Здравствуйте, samius, Вы писали:

V>>>>IO a = World -> (a, World)

S>>>Чистая — значит детерминированная + без побочных эффектов. Если по поводу побочных эффектов можно филосовствовать (ну там что они появились в новом экземпляре World), то с детерминированностью тут точно проблемы.

V>>Все вполне детерминировано. Просто World каждый раз разный. А если World одинаковый (мир, на момент запуска программы), то и результат всегда будет один.
S>Это значит что мы фиксируем мир, в котором я введу конкретную строку до того как "выполнилась" функция IO String, являющаяся результатом getLine? И в таком мире, в котором я ввожу лишь эту строку, считаем что функция-результат getLine детерминирована?

Да. Т.к. getLine интересует только ввод строки, если наш "мир" (или рантайм) будет поставлять всегда одну и ту же строку, то getLine будет возвращать один и тот же результат.

S>Я предпочитаю считать что в одном и том же мире я могу получить разный результат в IO a.

Каким образом?

S>>>Наоборот, main — чистая. чистая main строит нечистую функцию IO (). И эта нечистая функция-результат чистого main далее выполняется рантаймом. Я это себе так представляю.

V>>И main чистая и IO (), которое она вычисляет, тоже чистое, а вот рантайм уже да, во всю оперирует с миром.

V>>В целом граница достаточно тонкая и условная, важно понять, что концептуально IO -- обычная чистая ф-ия, просто она работает с миром.
S>Чистая — значит детерминированная уже сейчас.

Что значит детерминированная уже сейчас? Если мир будет одним и тем же, то и результаты будут одними и теми же. Другой вопрос, что сложно сделать один и тот же мир для программы.

V>>Вполне можно сделать какой-нить специальный "мир" для запуска программы, который, например, для getLine всегда будет подставлять одни и те же строки. Тогда (если программа, кроме как через getLine, с миром никак не реагирует) результат поведения программы будет детерминированным.
S>Вот когда будет специальный "мир", тогда и будем считать результат IO a детерминированным. А до тех пор, пока мы подавая один и тот же экземпляр мира будем получать различные результаты — увы.

С какой стати мы будем получать разный результат? Если интересующая программу часть мира будет одинаковой, то и результат будет одинаковым. Возьми тот же компилятор или БД. Если исходные файлы одинаковые, то и результат будет один и тот же, какими бы императивными компилятор или БД не были.

Здравствуйте, m e, Вы писали:

ME>D на правильном пути

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

Хотя это тут оффтопик по идее — он явно не декларативный язык. ))) Но вообще если бы у D была бы возможность линковать C++ библиотеки или же были хотя бы сделаны биндинги к основным нужным библиотекам (у D с этим заметно хуже чем даже у Хаскеля, не говоря уже про Питон), то я бы перешёл на него в большинстве мест. А так, пока только надеюсь что в будущем он всё же получит толчок в развитие инфраструктуры...

Здравствуйте, vshabanov, Вы писали:

V>Здравствуйте, samius, Вы писали:

S>>Это значит что мы фиксируем мир, в котором я введу конкретную строку до того как "выполнилась" функция IO String, являющаяся результатом getLine? И в таком мире, в котором я ввожу лишь эту строку, считаем что функция-результат getLine детерминирована?

V>Да. Т.к. getLine интересует только ввод строки, если наш "мир" (или рантайм) будет поставлять всегда одну и ту же строку, то getLine будет возвращать один и тот же результат.
Ключевое тут "если". А в том что оно так и будет, уверенности никакой нет.

S>>Я предпочитаю считать что в одном и том же мире я могу получить разный результат в IO a.

V>Каким образом?
Дело в том, что миру фиолетово, зафиксировал ли я его. Результат взаимодействия с ним недетерминирован. Можно сказать что по определению.

V>>>В целом граница достаточно тонкая и условная, важно понять, что концептуально IO -- обычная чистая ф-ия, просто она работает с миром.
S>>Чистая — значит детерминированная уже сейчас.

V>Что значит детерминированная уже сейчас? Если мир будет одним и тем же, то и результаты будут одними и теми же. Другой вопрос, что сложно сделать один и тот же мир для программы.
Зачем сделать? Если считать что IO a есть World -> (a, World), то можно написать (представить) функцию

getLine2:: IO (a, a)
getLine2 w = ((a1, a2), w1)
    where (a1, w1) = getLine w
          (a2, _ ) = getLine w

Предполагаемая чистота IO a должна гарантировать что такую функцию написать возможно и что a1 будет всегда совпадать с a2.
Однако, боюсь что это невозможно даже теоретически. Определение чистоты утверждает что любое взаимодействие с I/O нечисто. Безотносительно того, считаем ли мы мир аргументом функции или нет.

S>>Вот когда будет специальный "мир", тогда и будем считать результат IO a детерминированным. А до тех пор, пока мы подавая один и тот же экземпляр мира будем получать различные результаты — увы.

V>С какой стати мы будем получать разный результат? Если интересующая программу часть мира будет одинаковой, то и результат будет одинаковым.
А с чего ему быть одинаковым? Только с того что мы о нем так подумали?
V>Возьми тот же компилятор или БД. Если исходные файлы одинаковые, то и результат будет один и тот же, какими бы императивными компилятор или БД не были.
Работу компилятора легко представить деретминированной функцией. С БД уже сложнее, т.к. в запросе могут быть недетерминированные функции типа GETDATE.

Здравствуйте, samius, Вы писали:

S>Вот когда будет специальный "мир", тогда и будем считать результат IO a детерминированным. А до тех пор, пока мы подавая один и тот же экземпляр мира будем получать различные результаты — увы.
Эк Вы сурово. Вон в ООП вообще начинают с пустого мира, где даже дух божий не летает над водой -- и не пищат.

Здравствуйте, alexlz, Вы писали:

A>Здравствуйте, samius, Вы писали:

S>>Вот когда будет специальный "мир", тогда и будем считать результат IO a детерминированным. А до тех пор, пока мы подавая один и тот же экземпляр мира будем получать различные результаты — увы.
A>Эк Вы сурово. Вон в ООП вообще начинают с пустого мира, где даже дух божий не летает над водой -- и не пищат.
В хаскеле мир не полнее

Здравствуйте, samius, Вы писали:

S>>>Это значит что мы фиксируем мир, в котором я введу конкретную строку до того как "выполнилась" функция IO String, являющаяся результатом getLine? И в таком мире, в котором я ввожу лишь эту строку, считаем что функция-результат getLine детерминирована?

V>>Да. Т.к. getLine интересует только ввод строки, если наш "мир" (или рантайм) будет поставлять всегда одну и ту же строку, то getLine будет возвращать один и тот же результат.
S>Ключевое тут "если". А в том что оно так и будет, уверенности никакой нет.

Почему?

S>>>Я предпочитаю считать что в одном и том же мире я могу получить разный результат в IO a.

V>>Каким образом?
S>Дело в том, что миру фиолетово, зафиксировал ли я его. Результат взаимодействия с ним недетерминирован. Можно сказать что по определению.

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

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

V>>>>В целом граница достаточно тонкая и условная, важно понять, что концептуально IO -- обычная чистая ф-ия, просто она работает с миром.
S>>>Чистая — значит детерминированная уже сейчас.

V>>Что значит детерминированная уже сейчас? Если мир будет одним и тем же, то и результаты будут одними и теми же. Другой вопрос, что сложно сделать один и тот же мир для программы.
S>Зачем сделать? Если считать что IO a есть World -> (a, World), то можно написать (представить) функцию
S>

S>getLine2:: IO (a, a)
S>getLine2 w = ((a1, a2), w1)
S>    where (a1, w1) = getLine w
S>          (a2, _ ) = getLine w
S>

S>Предполагаемая чистота IO a должна гарантировать что такую функцию написать возможно и что a1 будет всегда совпадать с a2.

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

S>Однако, боюсь что это невозможно даже теоретически. Определение чистоты утверждает что любое взаимодействие с I/O нечисто. Безотносительно того, считаем ли мы мир аргументом функции или нет.

Подпробнее про теорию можно почитать здесь http://research.microsoft.com/en-us/um/people/simonpj/papers/marktoberdorf/mark.pdf

Там, кстати, не только теория. Работу с внешним миром из Хаскеля (IO/ffi/exceptions/concurrency) я изучал именно по ней. Да и когда, несколько лет спустя, почитал главу про семантику даже что-то понял. Т.е. по теоретической части там не сильный матан (все-таки Энтони Хоар помогал).

S>>>Вот когда будет специальный "мир", тогда и будем считать результат IO a детерминированным. А до тех пор, пока мы подавая один и тот же экземпляр мира будем получать различные результаты — увы.

V>>С какой стати мы будем получать разный результат? Если интересующая программу часть мира будет одинаковой, то и результат будет одинаковым.
S>А с чего ему быть одинаковым? Только с того что мы о нем так подумали?

Именно

V>>Возьми тот же компилятор или БД. Если исходные файлы одинаковые, то и результат будет один и тот же, какими бы императивными компилятор или БД не были.
S>Работу компилятора легко представить деретминированной функцией. С БД уже сложнее, т.к. в запросе могут быть недетерминированные функции типа GETDATE.

Хорошо, если GETDATE будет всегда возвращать одни и те же результаты? Полчуается, что внутри компилятора или БД будут всякие do/IO, но при этом они все равно будут чистыми ф-иями.

Здравствуйте, VoidEx, Вы писали:

VE>Здравствуйте, dsorokin, Вы писали:

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

VE>https://en.wikipedia.org/wiki/Functional_programming

VE>In computer science, functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data.

VE>Всё предельно чётко.

Мне больше нравится "определение" из книги Hutton "Programming in Haskell", 2005:

"What is functional programming? Opinions differ, and it is difficult to give a
precise definition. Generally speaking, however, functional programming can
be viewed as a style of programming in which the basic method of computation
is the application of functions to arguments. In turn, a functional programming
language is one that supports and encourages the functional style."

Лично для меня Common Lisp вполне подходит под это определение.

Здравствуйте, vshabanov, Вы писали:

V>Здравствуйте, samius, Вы писали:

V>>>Да. Т.к. getLine интересует только ввод строки, если наш "мир" (или рантайм) будет поставлять всегда одну и ту же строку, то getLine будет возвращать один и тот же результат.
S>>Ключевое тут "если". А в том что оно так и будет, уверенности никакой нет.

V>Почему?
Потому что мир отличается от того, что мы вообразили о нём.

S>>>>Я предпочитаю считать что в одном и том же мире я могу получить разный результат в IO a.

V>>>Каким образом?
S>>Дело в том, что миру фиолетово, зафиксировал ли я его. Результат взаимодействия с ним недетерминирован. Можно сказать что по определению.

V>По какому такому определению? У тебя внешний мир прямо что-то совершенно неопределенное, но реально на любую программу влияет ограниченный набор воздействий, и если эти воздействия будут одинаковыми, то и поведение программы будет одинаковым.
http://en.wikipedia.org/wiki/Pure_function

In computer programming, a function may be described as pure if both these statements about the function hold:

The function always evaluates the same result value given the same argument value(s). The function result value cannot depend on any hidden information or state that may change as program execution proceeds or between different executions of the program, nor can it depend on any external input from I/O devices.
Evaluation of the result does not cause any semantically observable side effect or output, such as mutation of mutable objects or output to I/O devices.

Но ты предлагаешь забыть о детерминированности лишь потому как мир можно представить внутренним полностью контроллируемым объектом

V>В обычных языках мир учитывается только неявно, по-этому и вылезают всякие недетерминированности. В хаскеле мир учитывается явно, что и делает ф-ии, оперирующие с ним (т.е. IO a) чистыми. Другое дело, что сам исходный мир все время разный и результат этих чистых ф-ий разный. Но важно, что сама по себе IO является чистой ф-ией над миром, хотя и выглядит как "какой-то кривой императивный язык".
Мне кажется, что ты неправильно себе это представляешь. Функции в хаскеле не оперируют с миром (я о тех, которые не считаются бэкдорами типа unsafePerformIO). Функции в хаскеле оперируют action-ами. Как оперирующие action-ами, они формально чисты. Но сами action-ы не являются чистыми.

S>>Зачем сделать? Если считать что IO a есть World -> (a, World), то можно написать (представить) функцию
S>>

S>>getLine2:: IO (a, a)
S>>getLine2 w = ((a1, a2), w1)
S>>    where (a1, w1) = getLine w
S>>          (a2, _ ) = getLine w
S>>

S>>Предполагаемая чистота IO a должна гарантировать что такую функцию написать возможно и что a1 будет всегда совпадать с a2.

V>Было бы запросто возможно, если был бы свой ограниченный мир, который мы можем контролировать. Однако прогам надо работать с внешним миром, по-этому интерфейс к внутренностям IO закрыт и с ним можно работать только через монадный bind.
То есть ты говоришь что функции чисты, если представить такой хороший внутренний мир. Но тут же говоришь что им приходится работать с внешним миром. Тогда наверное они не так уж и чисты, как ты предлагаешь считать?

S>>Однако, боюсь что это невозможно даже теоретически. Определение чистоты утверждает что любое взаимодействие с I/O нечисто. Безотносительно того, считаем ли мы мир аргументом функции или нет.

V>Подпробнее про теорию можно почитать здесь http://research.microsoft.com/en-us/um/people/simonpj/papers/marktoberdorf/mark.pdf
в этой теории написано примерно то, о чем и я:

getCharis an I/O action that, when performed, reads a character from the standard input (thereby hav-
ing an effect on the world outside the program), and returns it to the program as the result of the action.
putCharis a function that takes a character and returns an action that, when performed, prints the char-
acter on the standard output (its effect on the external world), and returns the trivial value().

Т.е. когда action-ы перфомятся, тогда они взаимодействуют с миром, плодят эффекты, получают недетерминированные результаты. Но программе на хаскеле нет нужды их перфомить вручную. Это сделает рантам, получив экшн как результат чистого вычисления main и подав ему мир.

V>Там, кстати, не только теория. Работу с внешним миром из Хаскеля (IO/ffi/exceptions/concurrency) я изучал именно по ней. Да и когда, несколько лет спустя, почитал главу про семантику даже что-то понял. Т.е. по теоретической части там не сильный матан (все-таки Энтони Хоар помогал).
Угу.

V>>>С какой стати мы будем получать разный результат? Если интересующая программу часть мира будет одинаковой, то и результат будет одинаковым.
S>>А с чего ему быть одинаковым? Только с того что мы о нем так подумали?

V>Именно
А что нам мешает так подумать с любой функцией в императивном программировании? Ну и что что мир не фигурирует в параметрах функции, считаем его зафиксированным, получаем что любая функция детерминирована

S>>Работу компилятора легко представить деретминированной функцией. С БД уже сложнее, т.к. в запросе могут быть недетерминированные функции типа GETDATE.

V>Хорошо, если GETDATE будет всегда возвращать одни и те же результаты? Полчуается, что внутри компилятора или БД будут всякие do/IO, но при этом они все равно будут чистыми ф-иями.
Если GETDATE будет возвращать один и тот же результат, нафиг она нужна, ее можно заменить константой!

Здравствуйте, m e, Вы писали:

ME>"может быть" здесь я употребил в смысле "возможно, что... но доказать не могу"

Ага. Т.е. это еще веселее чем в анекдоте про нашедшиеся ложки и оставшийся осадок: тут ложки даже и не терялись, но есть мнение, что потеряются.

ME>что значит "полноценность"?

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