Functional pearls

[lomeo]

Недавно на LTU проходила ссылка на Functional Pearls. Наконец то я до неё добрался и начал читать Richard Bird. How to Write a Functional Pearl. Понравившиеся, по исключительно субъективным причинам, моменты:

В одном из советов о том, как писать, Bird пишет: "Find an author whose style you admire and copy it (my personal favourites are Martin Gardner and Don Knuth).". Порадовало, собственно, наличие Мартина Гарднера в образцах подражания.


Во вторых, в примере решалки судоку, в коде не используются индексы для получения значений из матрицы. Когда я учил Haskell, мы с товарищем как раз писали такую решалку. В качестве одного из критерия сравнения декларативного и императивного подхода я тогда как раз понял то, что использование (!!), map ... [1..n] и тому подобное - это просто-напросто императивный код на функциональном языке. Избавляясь от подобного подхода, я сократил (и ускорил) программу. Собственно тогда я более-менее чётко понял, что такое декларативность и почувствовал, что она даёт.

Bird пишет об этой ситуации (с матрицей судоку) так:

Instead of thinking about coordinate systems, and doing arithmetic on subscripts to extract information about rows, columns and boxes, we have gone for denitions of these functions that treat the matrix as a complete entity in itself.

Geraint Jones has aptly called this style Wholemeal Programming

Wholemeal programming is good for you: it helps to prevent a disease called indexitis, and encourages lawful program construction.

Слово очень понравилось. На РСДН, например, замечен неоднократный оживляж по поводу паттерн-матчинга. Его превозносят, считая одной из основных черт функционального программирования. Не хочется его принижать - ПМ, действительно, вещь замечательная. Но у неё есть и недостатки, первый и главный из которых - это отсутствие сокрытия данных. Чуть поменялась структура - и вперёд по всему коду менять паттерны! Я стараюсь использовать ПМ для типов модуля внутри этого же модуля, а снаружи использовать комбинаторы над этим типом. И вот поэтому слово Wholemeal Programming мне очень нравится ;-)

Ну, и вообще насчёт статьи - метод, который применяется для разработки программы, очень интересен, что то вроде ручного fusion.

Comments

[deni-ok.livejournal.com]

>В одном из советов о том, как писать, Bird пишет: "Find an author whose style you admire and copy it (my personal favourites are Martin Gardner and Don Knuth).". Порадовало, собственно, наличие Мартина Гарднера в образцах подражания.

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


Про цельнозерновое программирование +10

О паттерн-матчинге на RSDN

[(Anonymous)]

>На РСДН, например, замечен неоднократный оживляж по поводу паттерн-матчинга. Его превозносят, считая одной из основных черт функционального программирования. Не хочется его принижать - ПМ, действительно, вещь замечательная. Но у неё есть и недостатки, первый и главный из которых - это отсутствие сокрытия данных. Чуть поменялась структура - и вперёд по всему коду менять паттерны! Я стараюсь использовать ПМ для типов модуля внутри этого же модуля, а снаружи использовать комбинаторы над этим типом.

Собсно "оживляш" там идёт просто из-за новой игрушки, со временем практика использования устоится и все недостатки пропишутся вначале в неявном кодексе использования (это даже уже наблюдается на том коде, что пишут на N), а потом уже на уровень code style tools/language restrictions/some else. А так вся эйфория из-за постоянного использования императива в котором кроме switch и if ничего нету, и тут когда появляется новое средство аля ПМ, то это как отдушина сразу возникает. И с туплами та же история.

С Уважением, Andir!

[thesz.livejournal.com]

Но у неё есть и недостатки, первый и главный из которых - это отсутствие сокрытия данных. Чуть поменялась структура - и вперёд по всему коду менять паттерны!

1. Нам в том поможет компилятор и
2. Это, оказывается, серъезная проблема, над которой работал и Вадлер в том числе.
От тут http://lambda-the-ultimate.org/node/2231 и тут http://lambda-the-ultimate.org/node/2232

[palm-mute.livejournal.com]

> Но у неё есть и недостатки, первый и главный из которых - это отсутствие сокрытия данных. Чуть поменялась структура - и вперёд по всему коду менять паттерны

Вроде бы всевозможные Pattern Guards, Active Patterns, Views и т.д. призваны эту проблему решить

[justbulat.livejournal.com]

>Но у неё есть и недостатки, первый и главный из которых - это отсутствие сокрытия данных

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

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

помню, как там выглядит конструкция поиска подстроки в строке на основе простейшей операции - сравнения двух символов. всё выражение целиком - это примерно 10-15 символов. первым делом из этих двух строк конструируется матрица(!) сравнения каждого исмвола из одной строки с скаждым сиволом из другой. затем пара редукций - и мы полчаем список всех позиций одной строки в другой

[nivanych.livejournal.com]

> wholemeal programming

Что же, мля, никто с более явной и развитой концепцией работать не хочет, а всё придумывает всякое полу-ad-hoc?...