Вопрос по обучению функциональному программированию

You learn Haskell for The Great Good?

Все «изложение функционального программирования» умещается в одно предложение: «Функциональное программирование - это программирование с использованием математических („чистых“) функций».

Если тебя интересует какой-то конкретный язык, спрашивай про конкретный язык.

You learn Haskell for The Great Good?

плюсую, тоже по ней учился, хотя нихрена и не понял и все забыл

У меня одного pdf-ки с arxiv не качаются?

Да. http://rghost.net/47731316

хз. норм кач

А нет, это с wget'ом что-то не так.

$ wget http://arxiv.org/pdf/1307.6701
--2013-07-28 19:48:52--  http://arxiv.org/pdf/1307.6701
Распознаётся arxiv.org... 128.84.21.199
Подключение к arxiv.org|128.84.21.199|:80... соединение установлено.
HTTP-запрос отправлен. Ожидание ответа... 302 Found
Адрес: http://arxiv.org/pdf/1307.6701.pdf [переход]
--2013-07-28 19:48:53--  http://arxiv.org/pdf/1307.6701.pdf
Повторное использование соединения с arxiv.org:80.
HTTP-запрос отправлен. Ожидание ответа... 403 Forbidden
2013-07-28 19:48:53 ОШИБКА 403: Forbidden.

$ curl http://arxiv.org/pdf/1307.6701.pdf > man.pdf
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  937k  100  937k    0     0   118k      0  0:00:07  0:00:07 --:--:--  165k
$ evince man.pdf
$ wget http://arxiv.org/pdf/1307.6701.pdf
--2013-07-28 19:50:05--  http://arxiv.org/pdf/1307.6701.pdf
Распознаётся arxiv.org... 128.84.21.199
Подключение к arxiv.org|128.84.21.199|:80... соединение установлено.
HTTP-запрос отправлен. Ожидание ответа... 403 Forbidden
2013-07-28 19:50:06 ОШИБКА 403: Forbidden.

Все «изложение функционального программирования» умещается в одно предложение: «Функциональное программирование - это программирование с использованием математических („чистых”) функций».

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

Все «изложение функционального программирования» умещается в одно предложение: «Функциональное программирование - это программирование с использованием математических („чистых”) функций».

Во-во-во. Я даже не знаю, ужасаться ли мне этому комментарию и своей глупости или идти в наступление и обвинять во всех грехах :). Ты бы еще «В начале было слово и слово было от болга и слово было бог вспомнил».

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

В принципе, как отправнапя точка пойдет книжка «High order Perl» http://hop.perl.plover.com/ . Это, наверное, близко к тому, что бы я хотел увидеть. Но она не покрывает многого, очень многого и все-таки не так фундаментальна. То есть возможно начинать с простых математических примеров было бы для меня интереснее. Возможно чисто математическое введение было бы лучше.

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

Можешь попробовать SICP (первые 3 главы). Там основы, примеры «математические», упражнения необязательно делать на схеме, перл вполне подойдет, рассказывают про «ФП» и немного про «ООП».

Годная ссылка, сохранил.

Спасибо.

А есть ли изложение функционального программирования «в духе Дьердя Пойа»

В смысле, максимально скучно и бессмысленно?

Мигель, я не столь умен как ты. Для меня Пойа - это пророк и путеводитель в этом темном и непонятном мире.

В смысле, максимально скучно и бессмысленно?

олололо!

конечно, доказать необходимость какой-то методологии в научном поиске вряд ли возможно, но кое-какие вопросы я могу задать

1. решал ли ты задачи, где подход к решению *вообще* не известен; например, есть задача на максимум, но стандартный подход «малая вариация» не подходит — т.е. не подходит после любой своей модификации

2. анализировал ли ты свой процесс поиска решения

3. и каковы были результаты анализа

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

Чего. Они ортогональны (см. Idris).

1. и где там видна ортогональность? (на http://www.idris-lang.org/ слово «effect» вообще не упоминается)

2. с какой стати ортогональность, если функциональное программирование — это просто частный случай — т.е. программирование без эффектов?

3. как в хаскеле/идрисе/фп-языке-по-твоему-выбору разрулить случай «вот эти вот функции имеют коммутирующие эффекты, а вот эти — нет?»

скажем, мы параллельно проверяем кучу ip на наличие smtp open relay, и операции проверки одного ip не коммутируют, а проверки разных ip — коммутируют (более сложный случай — коммутируют частично)

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

http://learnyouahaskell.com/chapters

1. Система эффектов реализована библиотекой написанной на Идрисе, см http://eb.host.cs.st-andrews.ac.uk/drafts/effects.pdf

2. Ват.

3. В хаскеле вероятно никак, в любом языке с зависимыми типами «разруливание» любых инвариантов в системе типов ограничено только фантазией и желанием таскать пруфы.

4. Допустим. Если ты уверен, что комбинация функций чистая, но не смог доказать это компилятору, то всегда есть unsafePerformIO. (К чему это вообще?)

1. Система эффектов реализована библиотекой написанной на Идрисе, см http://eb.host.cs.st-andrews.ac.uk/drafts/effects.pdf

интересно, прочту

но если у функций есть эффекты, то это уже не фп; а если ты не согласен, тогда какое твое определение фп?

4. Допустим. Если ты уверен, что комбинация функций чистая, но не смог доказать это компилятору, то всегда есть unsafePerformIO. (К чему это вообще?)

не-не-не

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

2. Ват.

ты бы на пальцах все же бы изложил идею ортогональности, т.к. у меня фп опять же сильно ассоциируется с non-strict evaluation

как я представляю, зависимые типы могут только запретить скомпилировать какое-то выражение, и *не могут* превратить non-strict evaluation в strict evaluation, а strict evaluation совершенно необходим для отдельных кусочков программы, где используются функции с некоммутирующими эффектами

У функций в ФП нет /сайд/эффектов. Например, (игнорируя существование _|_ и unsafe* функций) функция с типом :: a -> a имеет единственную имплементацию. Функция с тем же типом в скале (ну или любом другом ООП языке с поддержкой параметрического полиморфизма) может выполнить любое I/O перед тем как вернуть аргумент.

Ну, например, Agda/Idris/Coq все strict :)

Порядок выполнения «эффектов» не зависит от (ортогонален :) ) evaluation strategy. Например:

main = putStrLn "foo" >> putStrLn "bar"

И при strict, и при non-strict этот код сначала выведет «foo», потом «bar». Чтобы понять, что происходит, проще всего представить 2 уровня. Нижний («interpreter») требует команды от верхнего («evaluator»). Верхний пытается из

main = (>>) (putStrLn "foo") (putStrLn "bar") -- префиксная запись

собрать «AST», нижний его «интерпретирует». Неважно, с какой стороны подойти к собиранию этого «AST», оно всегда будет одним и тем же. Так как порядок обхода этого дерева фиксированный (в rts), то и результат всегда одинаковый.

              main
            /      \
 putStrLn "foo"  putStrLn "bar"

Важный момент тут в том, что «evaluation» IO значения не приводит к выполнению I/O пока до него не доберется «interpreter», что позволяет использовать IO как first-class (таскать в списках, использовать как аргументы к функциям, etc, если по-простому)

Само IO - это простейшая «система эффектов»: либо можно все (IO Int), либо ничего (Int). (Тут немного неправда, есть еще ST, позволяющая использовать только мутабельные структуры данных.). Языки вроде Идриса позволяют разделить IO на многожество разных частей, позволяющих, например, ограничить I/O работой с файлами.

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

Почитай про монаду ST. Она как раз позволяет некоторые нечистые функции превратить в чистые.

но кое-какие вопросы я могу задать

И зачем?

решал ли ты задачи, где подход к решению *вообще* не известен

Конечно. На мат-мехе иначе сложно.

анализировал ли ты свой процесс поиска решения

Конечно.

и каковы были результаты анализа

Основной результат — что никаких общеполезных способов облегчить этот поиск не существует. Нужно просто постоянно тыкаться в задачу (чтобы не забывать её ни на минуту) и ждать озарения.

Ответ по обучению функциональному программированию: не нужно обучать функциональному программированию.