![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
Functional pearls
Недавно на LTU проходила ссылка на Functional Pearls. Наконец то я до неё добрался и начал читать Richard Bird. How to Write a Functional Pearl. Понравившиеся, по исключительно субъективным причинам, моменты:
В одном из советов о том, как писать, Bird пишет:
Во вторых, в примере решалки судоку, в коде не используются индексы для получения значений из матрицы. Когда я учил Haskell, мы с товарищем как раз писали такую решалку. В качестве одного из критерия сравнения декларативного и императивного подхода я тогда как раз понял то, что использование
Bird пишет об этой ситуации (с матрицей судоку) так:
Слово очень понравилось. На РСДН, например, замечен неоднократный оживляж по поводу паттерн-матчинга. Его превозносят, считая одной из основных черт функционального программирования. Не хочется его принижать - ПМ, действительно, вещь замечательная. Но у неё есть и недостатки, первый и главный из которых - это отсутствие сокрытия данных. Чуть поменялась структура - и вперёд по всему коду менять паттерны! Я стараюсь использовать ПМ для типов модуля внутри этого же модуля, а снаружи использовать комбинаторы над этим типом. И вот поэтому слово Wholemeal Programming мне очень нравится ;-)
Ну, и вообще насчёт статьи - метод, который применяется для разработки программы, очень интересен, что то вроде ручного fusion.
В одном из советов о том, как писать, 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.
no subject
no subject
Активные паттерны - интересная идея из F#, я о ней читал на LTU (http://lambda-the-ultimate.org/archive/2007/04/09). Те же views, в принципе, сделаны удобно. Смысл тот же - удлиняем связь между АТД и его использованием, за счёт чего можем менять АТД не затрагивая код, где он используется.
no subject
этой фичи в языке нет, даже в ghc, это только предложение
а pattern guards, afair, это вот что:
f x | A y <- g x = ...
т.е. как раз возможность использовать в гуардах паттерны по обычным конструкторам типа, что как понимаешь, нифига ничего не скрывает
no subject
f x | A y <- g x
x здесь типа T1, а (A y) типа T2. Т1 - это абстракция, а T2 - представление этой абстракции, перевод в это представление через комбинатор g. При изменении абстракции меняются только сама абстракция и комбинатор перевода в представление. Функция f не меняется.
Т.е. Т1 мы всё таки скрываем и при этом при изменении правим только один модуль.