Видео выложено в двух вариантах - 100 Mb и 250 Mb. Файлы отличаются только степенью сжатия (битрейт 100 и 330 kbps соответственно), все остальные параметры у них одинаковы - 720×576, кодек h264, аудио в mp3 (48k).

Я пробовал заливать результат на Google Video, но после тамошнего пережатия картинка получается “нечитаемой”. Если кто владеет соответствующим кунг-фу - я буду рад услышать практические советы о том, как готовить подобные ролики для Google Video.

PS
Да, если кому-то хочется пятиканального звука и видео с “DVD-качеством” (MPEG2, 9000 kbps) - оригинальными материалами можно разжиться у меня, Макса Ищенко и ShaDOw.

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

Зачем это нужно? Допустим, решение какой-то задачи требует обработки нескольких массивов/списков/наборов данных. Если мы описываем решение в терминах операций над конкретными элементами (”a[i]=b[j]+c[j-i+1,j]“), у нас всегда есть риск упустить какой-то частный случай или совершить простейшую (и от этого вдвойне досадную) ошибку. Все наверняка хоть раз да и встречались с классическими ошибками типа “на единичку больше/меньше” и “выход за границы массива”.

Если же мы сумеем сформулировать решение в терминах операций над “целыми” списками/массивами, мы не только уменьшаем описанный риск, но и, как правило, получаем более короткий и читаемый код. Впрочем, довольно вступлений, перейдем к сути.
Для иллюстрации будет использоваться язык Haskell, для полного понимания происходящего полезно экспериментировать с приводимым кодом в какой-нибудь интерактивной среде (GHC, Helium или Hugs).

Задача: реализовать оптимальную стратегию игры в Wythoff’s game. Описание игры “на пальцах” выглядит так: представим себе шахматную доску, бесконечную в направлении вправо-вниз. На какой-то ее клетке стоит ферзь. Играют двое. На своем ходу игрок может передвинуть ферзя (по обычным правилам) на любую клетку, но только в направлении влево или вверх (или влево-вверх). Выигрывает тот, кто поставит ферзя в левый верхний угол доски.

Другое описание этой же игры выглядит так: есть две кучки одинаковых предметов. На своем ходу игрок может взять произвольное кол-во предметов из любой кучки, или же из обоих кучек сразу. Выигрывает тот, кто возьмет последний предмет. Игра выглядит детской и простой, но на самом деле является важным инструментом в теории игр: к ней и ее ближайшему родственнику - классической игре в Ним - сводится целый класс т.н. комбинаторных игр и изучению ее свойств посвящено множество книг и статей.

Выигрышная стратегия заключается в том, чтобы ставить ферзя только на такие (оптимальные) позиции, из которых оппонент, во-первых, не сможет закончить игру, и, во-вторых, не сможет сделать ход в какую-то другую оптимальную позицию, обладающую такими же свойствами. Если пронумеровать строки и столбцы шахматной доски, начиная с нуля, то координаты оптимальных позиций будут таковы (за подробным объяснением см. сюда):

Если мы каким-то образом вычислили список координат оптимальных позиций (назовем его “winning_positions”, предполагая, что он выглядит вот так: [(1,2),(3,5),(4,7),...]), то поиск оптимального хода реализуется “в лоб” (да простят меня за английские комментарии):

module Main where

import Data.List (delete)

-- | Find optimal move (da,db) for game position (a,b).
-- Here, `da' and `db' are numbers that should be
-- substracted from `a' and `b', respectively.
move a b = move' a b winning_positions

-- | Find position in the list of winning positions that
-- could be reached from (a,b) by either:
-- 1)substracting solely from `a' or `b'
-- 2)substracting simultaneously from `a' and `b'
move' a b ((x,y):rest)
  | a == b = (a,b)
  | a == x = (0,b-y)
  | a == y = (0,b-x)
  | b == y = (a-x,0)
  | b == x = (a-y,0)
  | a-x == b-y = (a-x,a-x)
  | a-y == b-x = (a-y,a-y)
  | otherwise = move' a b rest

main = loop
loop =
  do putStrLn "Enter two number that describe game position and press Enter"
     l <- getLine
     let [a,b] = map read $ words l
     putStr “My move: ”
     putStrLn $ show $ move a b
     loop

Дело за малым - получить список оптимальных позиций. Можно увидеть (или сходить по приведенной мною ссылке и почитать ), что “строка” является суммой “порядкового номера” позиции и “столбца”, а столбец, в свою очередь, является минимальным числом из ряда [1..], которое еще не было использовано в качестве “строки” или “столбца”.

Так и запишем (я постарался снабдить листинги гиперссылками на примеры использования задействованных функций, чтобы не перегружать текст примерами и объяснениям, так что если вы не знаете, что делают ($), map, zipWith и т.п. - кликайте на ссылки и читайте):

column = zipWith (+) [1..] row
row    = not_yet_used

winning_positions = zip row column

Осталось определить “not_yet_used” - список, в котором на позиции N стоит минимальное число, не использованное в N-1 предыдущих оптимальных позициях. Очевидно, что можно взять список [1..] и, двигаясь последовательно по списку выигрышных позиций, вычеркивать из [1..] использованные строки и столбцы. После каждого вычеркивания “выписывать отдельно” минимальное неиспользованное число (оно будет первым в оставшемся списке) и двигаться дальше. Код практически дословно повторяет сказанное:

not_yet_used = map head $ scanl remove [1..] winning_positions
  where remove lst (a,b) = delete b $ delete a lst

Вот и все, алгоритм реализован, и вы можете проверить, что, например, “move 12 6″ выдает правильный ход “(2,0)”, переводящий игрока в оптимальную позицию (10,6).

Теперь приглядимся повнимательнее к тому, как функции используют друг друга. Для вычисления “column” используется “[1..]” и “row”. Для вычисления “row” используется “not_yet_used”. Для нее, в свою очередь, нужны “winning_positions”. Для вычисления которой нужны … все те же “row” и “column”. Всё, круг замкнулся (см. рисунок).

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

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

А запускается вся эта карусель тогда, когда “scanl” из функции “not_yet_used” выдает на-гора начало своего результата - список [1..]. Первый элемент этого списка тут же попадает в значение “row”, после чего можно вычислить первый элемент результата “column”, после чего можно вычислить первую пару из “winning_positions”, которую можно использовать для вычисления следующего значения “not_yet_used” и т.д. и т.п (см. схему после этого абзаца). При этом вам вовсе не обязательно самому рисовать подобные картинки и прослеживать зависимости - за вас это сделает компилятор

Получившийся в результате список оптимальных позиций является бесконечным во всех практических смыслах этого слова. Например, если попытаться его напечатать (”print winning_positions”), то среда исполнения будет выводить оптимальные позиции до тех пор, пока вы ее не прервете.

Причем, для операций с бесконечными списками вовсе не требуется бесконечно много памяти Если скомпилировать программу, печатающую список всех оптимальных позиций и запустить ее, то можно заметить, что она занимает в памяти около 10 мб, и это значение со временем увеличивается очень плавно. А все дело в том, что значения “winnig_positions”, выведенные на экран, уже не требуются для дальнейших вычислений и тут же собираются сборщиком мусора, равно как и значения списоков “row” и “column”. Таким образом, в любой момент времени в памяти хранится по одному значению из списков “row”, “column” и “winning_position” + в памяти находится диапазон натуральных чисел от следующего минимально-неиспользованного до максимально-использованного (его использует в своих вычислениях функция “not_yet_used”). “Удлинение” этого диапазона и вызывает увеличение объема потребляемой памяти.

А неиспользованные элементы (или непрерывные диапазоны элементов) бесконечных списков представляются в Haskell в виде так называемых thunk-ов - “ссылок” на код, который их вычислит. Когда элемент “потребляется” для какого-то вычисления, thunk заменяется на вычисленное значение. Таким образом (упрощая), для хранения списка всех натуральных чисел [1..] достаточно хранить число “1″ + thunk с описанием, как вычислить последующие числа.

Надеюсь, что это краткий экскурс в ленивые вычисления с использованием бесконечных списков оказался для вас не только забавным, но и полезным. Удачи, до новых встреч!

PS
Disclaimer: данный код не является самым умным, самым быстрым или самым оптимальным способом решения поставленной задачи.

С интересом прочитал о том, как команда DOU участвовала в ICFPC-2007. В комментариях вспоминали меня и мой прошлогодний отчет, и я подумал, что многоуважаемой публике будет небезинтересно узнать о том, на какие грабли в этом году наступила команда Lazy Bottoms, чего мы достигли и что именно нам помешало занять место в top15 завершившегося соревнования.

Прошу любить и жаловать: отчет о ICFPC-2007 от команды Lazy Bottoms.

Через две недели у вас будет уникальный шанс проверить, чего стоят ваши убеждения, знания и навыки в состязании с другими программистами всего мира. Через две недели (20-го июля) начнется 10-е открытое соревнование по программированию ICFPC-2007.

Больше всего это похоже на программистские “бои без правил”. Про задание заранее неизвестно ничего - это может быть разработка raytracer-а, или программирование массы роботов для решения общей задачи или же реализация компьютерного игрока для игры в сложную командную игру.

У вас будет 72 часа на то, чтобы достигнуть успеха. Вы можете использовать любые языки программирования. Вы можете бороться самостоятельно или командой (ее размер - не ограничен). Вы можете сидеть в одной комнате или быть в разных углах земного шара. Вы можете спать по 12 часов или не спать вовсе. Вы можете использовать любые вычислительные ресурсы, которые вам доступны. Единственное ограничение - не участвовать более чем в одной команде одновременно.

Заинтересовались? Добавляйте в закладки страницу с таймером, отсчитывающим время до старта, регистрируйте вашу команду (это не обязательно, но желательно) и начинайте готовиться - осталось всего 12 дней.

А если вы сомневаетесь - почитайте отчеты участников о прошлогоднем соревновании, ссылки на которые собраны тут (в том числе - и отчет вашего покорного слуги).

Have fun!

Caml Trading: Experiences in Functional Programming on Wall Street

Yaron Minsky написал интереснейшую статью об опыте использования OCaml для написания программного обеспечения, задействованного в автоматизации торгов на фондовой бирже. Что заставило финансовую компанию отказаться от VBA и C# в пользу OCaml? Какие свойства языка привели к выбору в пользу OCaml, какие сильные и слабые стороны проявились в процессе написания и эксплуатации программного обеспечения? Как можно подсумировать опыт, накопленый с 2005-го года, и каковы перспективы использования OCaml для написания “больших” приложений?

Обо всем этом можно прочитать на 23 странице седьмого выпуска онлайнового журнала The Monad.Reader.

Lft/Scala

Scala, гибридный язык, сочетающий в себе элементы функциональной и объектно-ориентированой парадигм и компилирующийся в байт-код JVM, теперь обзавелся собственным web framework-ом.

Библиотека, называемая Lift, по утверждению авторов, делалась с оглядкой на лидеров в этом сегменте, и взяла от них все самое лучшее (… lift borrows from the best of existing frameworks including Seaside’s highly granular sessions and security, Rails fast flash-to-bang, Django’s “more than just CRUD is included”, and Erlyweb’s scalability for Comet-style applications.).

Утверждается, что код на lift/Scala получается таким же лаконичным, как при использовании Ruby On Rails, но при этом приложения исполняются в шесть раз быстрее и в многопоточном режиме. Кроме того, статическая типизация Scala позволяет устранить бОльшее количество ошибок на этапе разработки, а компиляция в байт-код JVM позволяет програмисту использовать любые существующие библиотеки, написанные на Java.

В качестве примера использования lift/Scala можно привести клон набирающей популярность “социальной IM-системы” Twittr.com. Код длиной в 900 строк позволяет (по утверждению автора) обслуживать более миллиона клиентов на системе из двух комьютеров на базе Core 2 Duo.

Window Manager на Haskell в 500 строк

В рамках графической подсистемы X Window, используемой в большинстве совеременных *nix-совместимых ОС, управление окнами (перемещение, максимизация/минимизация, расположение на экране, отрисовка бордюров и кнопочек и т.п.) выполняется не самой графической системой, а отдельной программой, называемой window manager.

Сушествуют десятки window manager-ов на любой вкус и цвет, но если в конце-концов выбор вас не удовлетворил, вы всегда можете написать свой, с нужными вам функциями и свойствами. Именно так поступили Don Stewart, Spencer Janssen и Jason Creighton - разочаровавшись в существующих tiling window manager-ах (ion3, wmii, ratpoison, …), они написали свой. На Haskell. Уложившись в 500 строк кода.

Дон Стюарт разместил в своем блоге детальный рассказ о том, как проектировался, писался и тестировался (автоматически!) этот проект. Изложение содержит большое количество кода на Haskell, но рекомендуется к прочтению даже тем, кто его не знает. Первая часть и вторая часть.

Следующая книжка из серии Pragmatic Programmer будет посвящена Haskell

Издательство Pragmatic Programmers, известное такими книгами, как “My job went to India”, “Agile Web Development with Rails и “Pragmatic Programmer: From Journeyman to Master”, приняло решение издать книгу о Haskell. Новость из первых рук сообщил (будущий) автор книги в своем блоге.

Очевидно, на положительное решение повлияли положительные обзоры книги “Programming Erlang”, которая месяц тому назад вышла на “финишную прямую” и попала в руки бета-тестеров.

Сегодняшняя статья будет посвящена ленивым вычислениям (lazy evaluation). Оставайтесь с нами, и вы увидите, как функция может использовать в качестве аргумента результаты своей работы.

В качестве языка для иллюстрирования взят Haskell. От читателя не требуется знания Haskell или его синтаксиса.

Рассмотрим такую задачу: дан текст, в котором используются специальные слова @label и @ref. С помощью @label определяются метки, а с помощью @ref делаются ссылки на них. Например, так:

Введение@label{intro}. Как известно, чушь бывает разная: зеленая (@ref{green}) и красная (@ref{red}).
...
Как мы уже отмечали (@ref{intro}), чушь бывает разная, и именно поэтому жизненно важно ...
...
Чушь красная@label{red}.
Не следует путать с чушью зеленой (@ref{green}).
...
Чушь зеленая@label{green}.
Радикально отличается от чуши красной (@ref{red}).
...

Нам необходимо написать программу, которая заменит метки их номером (в виде “[1]“, “[2]“, …), а ссылки - текстом “см. [1]“. Из нашего образца должно получиться:

Введение[1]. Как известно, чушь бывает разная: зеленая (см. [2]) и красная (см. [3]).
…
Как мы уже отмечали (см. [1]), чушь бывает разная, и именно поэтому жизненно важно …
…
Чушь красная[2].
Не следует путать с чушью зеленой (см. [3]).
…
Чушь зеленая[3].
Радикально отличается от чуши красной (см. [2]).
…

Классический алгоритм таков: проходим по тексту, собирая метки в порядке следования и назначая им номера. Проходим второй раз, заменяя метки и ссылки на вычисленые номера. Второй проход необходим, т.к. нам могут встретиться ссылки на метки, определенные дальше по тексту. Будем програмировать “сверху вниз”:

> module Main where
> import Data.List
> import Text.Regex.Posix
> import Control.Arrow
>
> main = do
>   txt <- readFile "sample.txt"
>   let numbering = collectLabels txt
>   let result = replaceLabels numbering txt
>   writeFile "sample.out" result

Тут txt, numbering и result - это не имена переменных, а имена, связанные (bound) с выражениями. Другими словами мы можем использовать numbering для того, чтобы быстро сослаться на результат применения функции collectLabels к выражению, связанному с именем txt. Можно связывать имена со значениями несколько раз, при этом более “вложенное” связывание перекрывает внешнее (как и в случае с именами локальных переменных в императивных языках программирования).

Поскольку мы идем “сверху вниз” и реализации collectLabels и replaceLabels у нас еще нет, так и напишем:

 > collectLabels = undefined
 > replaceLabels = undefined

Сохраняем наше творчество в файл “labeling.hs”. Запускаем ghci (интерактивную среду, прилагающуюся к компилятору GHC), в появившемся промпте вбиваем “:load labeling.hs”.

Ура, наша программа компилируется, хотя ничего разумного пока еще не делает. Мы еще не знаем, как именно будут реализованы функции collectLabels и replaceLabels, поэтому их тело состоит из одного примитива undefined. Использование undefined позволяет нам по ходу написания проверять правильность того, что мы пишем, начиная с самых первых строк. Как минимум, мы можем проверять, что компилятору удается выполнить вывод типов (type inference), т.е. определить, какой тип у всех выражений и функций, использованых в нашей программе, и проверить эти типы на соответствие друг другу (type checking).

Компиляторы C++/Java всегда выполняют проверку типов, но возможности вывода типов у них сильно ограничены. Упражнение номер один для пытливого читателя - написать минимальный компилирующийся “скелет”, аналогичный приведеному, на C++/Java.

Начнем со сбора меток. Нам нужно найти в тексте все вхождения @label{xxx} в порядке упоминания и сложить их в какую-то структуру данных. Например, в список. Для извлечения текста используем сравнение с регулярным выражением:

> collectLabels txt =
>   let matches = ( txt =~ "@label\\\\{([^}]*)\\\\}” :: [[String]] )
>       in map (!!1) matches

Явно указывая тип возвращаемого значения для ф-ии (=~), мы заставляем библиотеку Text.Regex.Posix выбирать один из многих вариантов представления результата сравнения с регулярным выражением (всего их более 15-и). В данном случае нас интересует список [весь_текст_совпадения, текст_группы_1, текст_группы_2, ...] для каждого совпадения с образцом. Пример ожидаемого результата: [["@label{ccc}","ccc"],["@label{bbb}","bbb"]].

В каждом списке-результате нас интересует второй элемент - имя метки. Ф-ия извлечения элемента списка по номеру имеет имя (!!) - например, второй элемент списка lst можно получить выражением lst!!1. Поскольку нам надо применить операцию ко всем результатам, воспользуемся ф-ией map и приемом, называемым “частичное применение” (partial application или currying).

Чтобы этот кусок кода было проще понять, обратимся к ghci. Используем его для того, чтобы поиграться с кусками кода и лучше понять, что именно они делают:


Можно просто проверить, совпала строка с регулярным выражением или нет
*Main> “@label{aaa} some text @label{bbb} some more text” =~ “@label\\{([^}]*)\\}” :: Bool
True

… или получить полный текст всех совпадений
*Main> “@label{aaa} some text @label{bbb} some more text” =~ “@label\\{([^}]*)\\}” :: [String]
["@label{aaa}","@label{bbb}"]

… или полный текст всех совпадений, плюс - текст всех подгрупп
*Main> let matches = “@label{aaa} some text @label{bbb} some more text” =~ “@label\\{([^}]*)\\}” :: [[String]]
[["@label{aaa}","aaa"],["@label{bbb}","bbb"]]

… из которого потом можно извлечь либо текст совпадения
*Main> map (!!0) matches
["@label{aaa}","@label{bbb}"]

… либо содержимое первой подгруппы.
*Main> map (!!1) matches
["aaa","bbb"]

Кроме того, мы можем посмотреть, что компилятор думает о типе определенного выражения:
*Main> :type map (!!1)
map (!!1) :: [[a]] -> [a]


Если вы использовали функцию map в Perl, Python или Ruby, то знаете, что ей нужно давать функцию от одного аргумента. В то же время (!!) - это функция от двух аргументов (список и позиция_в_списке). Однако, если функции (!!) дать всего один аргумент, то в результате получится новая функция от одного аргумента. Это и есть частичное применение.

Особо обратите внимание на последний пример: используя информацию о том, что (!!) возвращает элемент списка, компилятор самостоятельно вычислил, что выражение-функция map (!!1) будет преобразовывать список списков в список просто значений. Самостоятельно посмотрите на тип функций map, (!!) и (!!1), чтобы понять, как именно компилятор произвел вывод. Подобный алгоритм выведения типов используется также в языках Clean, ML, OCaml, Scala, Nemerle, D. Ожидается, что вывод типов появится в C# 3.0 и Perl 6 (помните, что я говорил о влиянии ФП на mainstream языки?).

Как мы видим, функции не только могут быть использованы в качестве аргументов в вызовах функций, но и могут быть результатами вычисления выражений. В этом смысле функции ничем не отличаются от прочих базовых типов языка - чисел, символов, списков. Говорят, что функции являются полноправными сущностями (first-class citizens). В качестве упражнения номер два можете попробовать определить на C++/Java аналоги функций map и !! так, чтобы их можно было комбинировать в стиле map (!!1) и самостоятельно сделать вывод о том, являются ли функции полноправными сущностями в этих языках.

Проверим наш код:


*Main> collectLabels “some text@label{one} with labels@label{two}\nand several lines@label{three}”
["one","two","three"]


Быстро закрепим пройденый материал: мы увидели кусок программы на функциональном языке Haskell. Язык - со строгой типизацией (как в C++/Java), что не мешает существованию интерактивной среды исполнения (interactive top-level), как в Python. Для создания программы используется создание новых функций путем комбинирования библиотечных функций, и функций, определенных пользователем. Отсуствие изменяемых переменных (mutable variables) пока что сильно не мешает.

Теперь напишем замену меток и ссылок номерами. Имена меток у нас уже собраны в список. Номер, на который надо заменять метку - это ее позиция в этом списке. Нам надо пройтись по всему тексту, находя специальные слова и заменяя их номерами.

Нам нужно разделить исходный текст на строки, которые в свою очередь разбить на слова. Среди слов нам надо найти “специальные” и заменить их на номера, после чего собрать слова в строки, а строки - в текст. Так и запишем:

> replaceLabelsUgly labelList txt = unlines ( map unwords ( map (map process) ( map words ( lines txt ))))
>   where process = undefined

Люди, страдающие лиспофобией, уже бьются в припадке и хрипят “Скобки! Уберите скобки! Опять эти чертовы скобки! “. Пожалуй, они в чем-то правы. Перепишем эту функцию так:

> replaceLabelsBetter labelList txt = unlines $ map unwords $ map (map process) $ map words $ lines txt
>   where process = undefined

Уже лучше. “Прикольный синтаксический наворот” - скажут многие. Однако, это не выверт в синтаксисе языка. Тут использована функция ($), которая объявлена как инфиксный оператор и определена так:

f $ x = f x

Получается, что $ - это такой способ композиции функций, только и всего. И в самом деле, легко убедиться, что f (g x) = f $ g x. Можно даже взять и переписать функцию replaceLabels с использованием композиции функций в чистом виде:

> replaceLabelsPointfree labelList = unlines . map unwords . map (map process) . map words . lines
>   where process = undefined

Обратите внимание, что в этой форме записи у replaceLabelsPointfree стало на один аргумент меньше, как это и происходит в математической нотации. Мы пишем f(x) = ... и g(x) = ..., но t = f . g.

Впрочем, тут могут объявится любители Ruby и сказать “все равно эта функция записана криво и непонятно. Что за дела? Чтобы ее понять, надо читать ее с конца. То ли дело запись вида txt.to_lines().map({|l| l.words()}).map ..., которую можно нормально прочесть слева направо”.

Что ж перепишем так, чтобы нормально читалось слева направо:

-> replaceLabels labelList = lines >>> map words >>> map (map process) >>> map unwords >>> unlines
->   where process = undefined

Как можно догадаться, (>>>) - это еще одна функция, позволяющая записать композицию ф-ий вот так, “шиворот навыворот”, в виде, напоминающем shell pipes из Unix-а.

Ну, тут уже явно возмутятся даже те, кто честно пытался вникнуть в написанное без перенесения на Haskell опыта работы со своим любимым языком программирования. “И это называется нормально?” - скажут они. “Тут же нифига не понятно!”.

Ну, раз непонятно, надо “мерять хвост частями” с помощью ghci:


*Main> lines “this is a\nsample\nmultiline text”
["this is a","sample","multiline text"]

*Main> lines >>> map words $ “this is a\nsample\nmultiline text”
[["this","is","a"],["sample"],["multiline","text"]]

*Main> lines >>> map words >>> map unwords $ “this is a\nsample\nmultiline text”
["this is a","sample","multiline text"]

*Main> lines >>> map words >>> map unwords >>> unlines $ “this is a\nsample\nmultiline text”
“this is a\nsample\nmultiline text\n”


Теперь осталось разобраться с тем, что стоит между map words и map unwords. Если process w проверяет, не является ли слово w специальным, и заменяет его на номер, то map process ws выполнит эту операцию для всех слов в ws. Если ws - это список слов, стоявших в одной строке, то нам осталось применить эту операцию ко всем строкам текста, чтобы обработать его полностью. Для этого и нужен второй, внешний map. Получаем, что обработка все слов текста - это и есть map (map process).

Быстро закрепим пройденый материал: мы увидели, как возможность объявлять функции инфиксными операторами с нужным приоритетом позволяет гибко создавать новые управляющие конструкции языка и, фактически, создавать удобный нам синтаксис. Прослеживается типичный шаблон (pattern) програмирования на функциональных языках - создание “конвейера” из функций, последовательно применяющих к исходным данным ряд преобразований для получения конечного результата.

Нам осталось определить функцию process. Она должна работать следующим образом: все слова вида @label{xxx} заменять на “[номер метки xxx]“, все слова @ref{xxx} заменять на “см. [номер метки xxx]“, а все прочие слова - не трогать. С вашего позволения, я сразу приведу соответствующих код, без подробных объяснений.

> replaceLabels labelList = lines >>> map words >>> map (map process) >>> map unwords >>> unlines
>   where process w | isInfixOf "@label{" w = replace ""     w
>                   | isInfixOf "@ref{"   w = replace "see " w
>                   | otherwise             = w
>
>         -- Эта функция заменяет ссылку/метку в слове `w' на ее [номер], предваряя [номер] строкой `prepend’
>         replace prepend w =
>           — Слово “Введение@label{aaaa}.” будет разбито на части “Введение”, “aaa” и “.”,
>           — из которых мы потом соберем результат.
>           let [[_,prefix,label,suffix]] = ( w =~ “(.*)@.*\\\\{([^}]*)\\\\}(.*)” :: [[String]] )
>               in prefix ++ prepend ++ “[" ++ idx label ++ "]” ++ suffix
>
>         — Возвращает позицию `l’ в списке `labelList’ (нумерация начинается с 1).
>         idx l = case elemIndex l labelList of
>                      Just x  -> show (x+1)
>                      Nothing -> error $ “Label “++l++” is not defined”

Я надеюсь, что даже минимальный опыт работы с python и ruby позволит без особого напряжения прочесть и понять этот код. Возможно, вам также поможет пример функции, которая для четных аргументов возвращает “fuzz”, а для нечетных - “buzz”:

fuzzbuzz x | even x    = "fuzz"
           | odd  x    = "buzz"
           | otherwise = "something is odd ..."

Проверим наш код:

*Main> main

В файле “sample.out” должен оказаться текст с замененными ссылками.

Тут самое время спросить: “НУ И ЧТО?”. Казалось бы, до сих пор мы не сделали ничего необычного и отличающегося от того, что мы делали бы при программировании на любом другом императивном языке. Ну, разве что, обошлись без переменных

Наберитесь еще немного терпения, мы уже подобрались “гвоздю программы”. Попробуем соединить сбор меток и замену ссылок в одну функцию. Предположим, что у нас уже есть полученый каким-то волшебным образом список всех меток в документе, назовем его allLabels. Откуда он взялся? А черт его знает. Допустим, мы сами прислали его себе из будущего, из того момента, когда мы уже обработали весь файл и знаем полный список меток

По-прежнему будем обрабатывать текст по словам, но чуть-чуть изменим алгоритм: если в слове есть ссылка, то использует allLabels для вычисления ее номера. Если же в слове есть метка, то используем allLabels для вычисления ее номера и добавим метку в список labelList. Зачем нам нужен labelList? Ну, должен же откуда-то взяться в будущем список меток, который мы пошлем себе в прошлое

Вашему вниманию предлагается функция process' (апостроф - это допустимый символ в имени функции), которая обрабатывает слово w, используя словарь меток allLabels и аккумулятор labelList, куда мы добавляем все найденые метки.

> process' (_,labelList,allLabels) w
>   | isInfixOf "@label{" w = replace ""      True
>   | isInfixOf "@ref{"   w = replace "see "  False
>   | otherwise             = (w, labelList, allLabels)
>
>   -- Заменяем ссылку/метку в слове `w' на ее номер, предваряя его строкой `prepend'. Если `add' == True,
>   -- добавляем метку в список labelList
>   where replace prepend add =
>           let [[_,prefix,label,suffix]] = ( w =~ “(.*)@.*\\\\{([^}]*)\\\\}(.*)” :: [[String]] )
>               labelList’ = if add then (label:labelList) else labelList
>             in (concat [prefix, prepend, "[", idx label,"]“, suffix], labelList’, allLabels)
>
>         idx l = case elemIndex l allLabels of
>                      Just x  -> show (x+1)
>                      Nothing -> “Label “++l++” is not defined”

Кроме того, несколько изменим процесс обработки всего текста: вместо того, чтобы превращать его в список списков слов, превратим его в “плоский” список слов, который будет удобно обработать функций process'. Чтобы можно было собрать текст обратно, сохранив разбиение на слова, свяжем в с каждым словом номер строки, в которой оно (слово) стояло. После замены ссылоку/меток собирем слова в цельный текст, используя сохраненную информацию о том, какие слова были в какой строке.

> process = combineFromWords . replaceLabels . splitToWords
>   where
>   splitToWords txt = unzip $ concat $ zipWith tagWords [1..] $ lines txt
>   replaceLabels (tags, ws) = zip tags (processWords ws)
>   combineFromWords ws = unlines $ map (unwords . map snd) $ groupBy (comparing fst) ws
>   tagWords lineNo line = zip (repeat lineNo) (words line)
>   comparing f a b = (f a) == (f b)

Пару примеров для облегчения понимания этого куска (используйте ghci, чтобы увидеть типы и “попробовать на зуб” все функции, которые я не упомянул в этих примерах):


*Main> zip [1..] $ lines “aaa bbb ccc\nddd eee fff”
[(1,"aaa bbb ccc"),(2,"ddd eee fff")]

*Main> let l = zipWith (\lineNo line -> zip (repeat lineNo) (words line)) [1..] $ lines “aaa bbb ccc\nddd eee fff”
[[(1,"aaa"),(1,"bbb"),(1,"ccc")],[(2,"ddd"),(2,"eee"),(2,"fff")]]

*Main> unzip $ concat l
([1,1,1,2,2,2],["aaa","bbb","ccc","ddd","eee","fff"])


А теперь, собственно, создадим нашу “машину времени” - функцию, которая получит результаты работы функции process' (собраный списко меток) и “отправит его в прошлое” - передаст в качестве аргумента … самой функции process'.

> processWords ws =
>   -- Из списка слов ["@label{aaa}","@ref{aaa}","ccc"] получаем список
>   — [ ("[0]“,["aaa"],все_метки_из_будущего)
>   — , (”см [0]“, ["aaa"], все_метки_из_будущего)
>   — , (”ccc”, ["aaa"], все_метки_из_будущего)
>   — ]
>   — Нас интересует последий элемент этого списка, который содержит список всех найденых меток
>   let result = drop 1 $ scanl process’ ([],[],reverse collectedLabels) ws
>       — Извлекаем список найденых меток, чтобы использовать его …
>       — … в предыдущей строке в качестве аргумента для process’ !
>       (_,collectedLabels,_) = last result
>       — Конечным результатом является список обработаных слов, без информации о найденых метках.
>       in map discardLabelLists result
>   where discardLabelLists (w,_,_) = w

Чтобы проверить, что этот код действительно работает, изменим функцию main:

> main' = do
>   txt <- readFile "sample.txt"
>   writeFile "sample.out" $ process txt

Выполнив main', вы можете убедиться, что все метки и ссылки в действительности были заменены номерами. Черная магия? Отнюдь. Но как …?

Использование в вычислениях еще не посчитаных значений становится возможным благодаря так называемой “ленивой” схеме вычислений (lazy evaluation) выражений в языках функционального программирования. При использовании этой схемы результатом выражения let y = ((f x) + (g x)) является не фактическая сумма, а что-то вроде ссылки на код, который эту сумму посчитает, когда нам понадобится значение y (я намерено опускаю технические детали). Если значение нам не понадобится - то и вычисление фактически не произойдет.

Таким образом, даже если вставить в произвольное место программы выражение let foobar = sum ( map (^2) [1..1000000000] ), можно не боятся, что программа будет тратить время на подсчет суммы квадратов всех чисел от одного до ста миллионов. Если мы нигде явно или косвенно не используем символ foobar, то это вычисление просто не произойдет.

Возвращаясь к нашему коду, становится понятно, что использование функции idx l не приводит к фактическому немедленному поиску метки l в списке allLabels. Вместо него создается “замороженный код” (thunk), который произведет этот поиск тогда, когда в нем будет необходимость. А необходимость эта появляется аж в самом конце программы, когда мы выводим результат обработки в выходной файл. Естественно, в этот момент времени у нас уже есть полный список меток, использованых в обрабатываемом тексте.

Получается, что я всех обманул - мы не отправляем “в прошлое” результаты вычислений, мы как бы “отправляем в будущее” сами вычисления с пометкой “до востребования”.

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

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

-- Функция `fib' возвращает список чисел Фибоначчи
fib = 1:1:(zipWith (+) fib (tail fib))

-- Функция `primes' возвращает список простых чисел
primes = primes' [2..]
  where primes’ (n:ns) = n : primes’ [ y | y <- ns, y `mod` n /= 0] 

– Функция ralign выравнивает список строк вправо:
ralign xs = [ rjustify m x | x <- xs ]
  where
  m = maximum [ length x | x <- xs ]
  rjustify m x = replicate (m - length x) ‘ ‘  ++ x

Если эта статья вызовет интерес, то в следующих выпусках нашей программы ожидайте: работа с бесконечными списками и бесконечными структурами данных, зачем нужны в реальной жизни катаморфизмы (foldr) и анаморфизмы (unfoldr) списков и многое другое

PS
Текст этой статьи можно сохранить в файл с суффиксом “.lhs” (literate Haskell), и его можно будет без изменений загружать и исполнять в ghci как программу.

PPS
Ссылки для самостоятельного чтения:

• Перечень учебных текстов по Haskell на Haskell Wiki. Беззастенчивая реклама: “Hitchhickers guide to Haskell” написан вашим покорным слугой.
• Wikibook по Haskell
• OCaml Tutorial

В заголовке нет опечатки - это именно “ФЯ”, а не “Я”. Это сокращение означает “функциональные языки”, и речь в статье пойдет о функциональном программировании (FP), точнее, даже не о нем самом, а о том, стоит ли тратить свое драгоценное время на знакомство с ним.

В сети можно найти десятки вводных статей о FP, как на русском, так и на английском. Зачем писать еще одну? Чем эта статья будет отличаться от уже существующих?

Большинство существующих источников начинаются с описания того, что такое FP (и зачастую этим и ограничиваются). Очевидно, предполагается, что читатель сам проникнется полезностью принципов FP, увидит области его применения, и на него снизойдет просветление

Но, как показывает практика, просветление (в виде способности с первого взгляда видеть корректное и элегантное решение проблемы в выбранной парадигме программирования) никогда не приходит вот так сразу, после первого знакомства с темой.

Как правило, первая реакция на знакомство с чем-то радикально новым - это “культурный шок“, и FP в этом смысле не исключение. Типичная реакция может выглядеть так: “Как, жить без глобальных переменных? Что вы говорите, не просто без глобальных, а без переменных вообще? Без объектов и методов, без инкапсуляции? Тю, придурки, на дворе 21 век, а они без объектов… Нафига это надо? Пойду лучше GoF почитаю”.

Так вот, эта статья ставит целью в первую очередь дать ответ на вопрос “нафига знать/изучать/использовать FP?”.

Итак, не откладывая в долгий ящик:

Зачем же стоит изучать FP?

1. Чтобы ознакомиться с новой парадигмой программирования. Изучение новой парадигмы программирования приведет к расширению вашего кругозора, освоению новых подходов и вообще позволит взглянуть на все, что вы делаете под новым ракурсом. Вы не обязательно начнете применять все изученное на практике, но знание наверняка пойдет вам на пользу. Если вы сомневаетесь - подумайте, будет ли полезно человеку, программирующему процедурно, изучить OOP, даже если он никогда не будет программировать на C++ или Java?

   Возможно, со стороны будет проще проникнуть в суть уже известных вещей и увидеть не только их положительные и отрицательные стороны. После знакомства с мультиметодами станут видны недостатки модели передачи управления в OOP и OOP-инкапсуляции вообще. После изучения параметрического полиморфизма станут видны ограничения “inclusion полиморфизма” (того самого, который входит в знаменитую OOP-тройку “полиморфизм, инкапсуляция, абстракция”).

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

2. Чтобы повысить свою производительность. Многочисленные статьи утверждают, что использование функциональных языков способно увеличить скорость написание программ, уменьшить время на отладку и т.п. Впрочем, сложно верить статьям, хочется примеров из реальной жизни.

   Взгляните на перечень языков, которыми пользовались победители соревнований ICFPC, в рамках которых необходимо за три дня реализовать довольно объемную алгоритмически сложную систему, или изучите статистику, собранную Project Euler. Вы обнаружите, что существенная часть тех, кто выступил лучше всех (или попал в верхние 20%) использовала тот или иной язык функционального программирования.

   Причем, если авторов ICFPC еще можно при желании заподозрить в предвзятом отношении к участникам, использовавшим функциональные языки, то projecteuler.net должны быть в этом смысле вне подозрений.

3. Чтобы понять, как можно связать программирование и математику. Наконец-то можно будет получить ответ на вопрос, зачем вообще придумали эти чертовы частично-рекурсивные функции и лямбда-исчисление, или - о ужас - теорию категорий. Более того - окажется, что эта- и бета-редукции - это мощный инструмент оптимизации программ, а теория категорий помогает писать generic код.
4. Чтобы поглубже узнать то, что вы уже наверняка и так использовали (хотя бы раз). Многие принципы и инструменты, впервые появившиеся в функциональных языках, рано или поздно просачиваются в mainstream языки и получают широкое распространение. Примерами могут служить функции “map” и “filter” (”grep”) в perl и python, list comprehensions в python, анонимные функции в этих же языках или анонимные методы в Java, весь язык XSLT целиком (хотя тех, кто придумал его синтаксис, убить мало), новомодный механизм LINQ и многое другое.
5. Чтобы быть в курсе новинок в области языков программирования. В настоящее время в мире ведутся интенсивные исследования в области теории языков программирования.

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

   Примерами могут служить currying, монады, software transactional memory, polymorphic variants, функции-как-процессы, их автоматическая миграция и прозрачное масштабирование runtime. К сожалению, я отступаю от своего собственного правила, и даю ссылки на “что”, без объяснения “зачем”, т.к. тут материала еще на 10 статей.

PS
Традиционно те, кто впервые сталкивается с FP, одним из первых задают вопрос: “ну хорошо, если все так замечательно, то где серьезный софт, написаный на этих языках?”. Почти наверняка это вопрос возникнет и у читателей этой статьи, и лучше ответить на него сразу:

• на Erlang написан Jabber server ejabberd, который используется, в частности, на серверах jabber.kiev.ua и jabber.ru
• на OCaml написан один из самых функциональных P2P клиентов mldonkey
• на Haskell написана распределенная система контроля версий darcs

UPD:
Дополнения и исправления по материалам присланых комментариев:

• Тот полиморфизм, который в OOP - это inclusion polymorphism. А ad-hoc - это из процедурного стиля. Fixed.
• Вместо альфа-редукции следует читать эта-редукции. Fixed.

Дополнительный списко примеров real-world софта на ФЯ:

• Единственная уже работающая реализация perl6 сделана на Haskell: pugs
• Haskell используется для финансовой аналитики в Credit Suisse: статья
• Galois Connectios разрабатывает на Haskell и OCaml инстументы и приложения в области криптографии и информационной безопасности

Надеюсь, что вы вынесли для себя из этой статьи что-то полезное. Я буду рад услышать ответную реакцию (в виде комментариев или писем на dastapov@gmail.com). Если статья вызовет интерес - возможно, на DOU появится постоянный раздел, посвященный FP.