Recycled Bin

INC

Mon, 03 Mar 2008 08:08:11 GMT

0x20

об абстрагировании

Mon, 25 Feb 2008 15:17:51 GMT

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

Здесь (thesz)

ЙО!

Fri, 22 Feb 2008 18:40:40 GMT

Видели уже наверное:
http://absurdopedia.wikia.com/wiki/Haskell

Лем живее всех живых

Thu, 07 Feb 2008 13:32:19 GMT

Трурль и Клапауций опять спорят. Теперь уже о том, что называть функциональным языком.

typechecker для dependent types system

Sun, 27 Jan 2008 00:03:33 GMT

Заинтересовал меня всё таки kurilka тотальным ФП, а у deni_ok и thesz я понахватался ссылок и умных слов. Ну, ещё и dependent types в стороне не остались.

Подумал, что total fp будет неплохо смотреться для программирования на типах - гарантия завершения будет тут очень кстати.

К сожалению, "по семейным обстоятельствам" я сейчас не в силах заняться чем нибудь серьёзно, поэтому всё, что я здесь пишу - скорее для себя, чтобы не забыть. Написано очень нудно (это тоже для себя, извините - я тупой) и сумбурно (а это так получилось).

Итак что здесь? (чтобы вы решили читать или нет)
Здесь размышления о том, как должен работать тайпчекер в системе с зависимыми типами. Я пытаюсь придумать приёмы, позволяющие строить гарантировано завершающиеся доказательства/опровержения.

Допустим, у нас есть тайп чекер, который разбирает следующее определение:

append :: List a n -> List a m -> List a (n + m)
append []     ys = ys
append (x:xs) ys = x : (xs `append` ys)

Это вы наверняка уже сто раз видели, но я для проформы повторю основные определения: List имеет тип (kind в терминах Haskell) - * -> Nat -> *:

data List :: * -> Nat -> *
    = []  :: List a 0
    | (:) :: a -> List a n -> List a (n + 1)

Nat - тип натуральных чисел:

data Nat :: *
    = Z :: Nat
    | S :: Nat -> Nat

Запись вида 0, 1, 2... всего лишь синтаксический сахар для Z, S Z, S (S Z)... А запись (n + 1) - сахар для S n. Вот, например, как этот сахар используется в определении функции (+):

(+) :: Nat -> Nat -> Nat
0 + m = m                   -- аналогично Z + m = m
(n + 1) + m = (n + m) + 1   -- аналогично (S n) + m = S (n + m)

Итак, нашему тайпчекеру надо проверить тип функции append.

Для первой части определения вроде бы всё просто (на самом деле нет, но мы это рассмотрим дальше). Из [] мы сопоставляем типы List a n и List b 0, находим, что наиболее общий тип, который входит в эти два - это List a 0 (подробности, как мы это делаем, неважны). ys :: List a m, а значит, нам надо убедиться, что результат (ys справа) имеет тип List a (0 + m). Для этого мы должны доказать, что List a m (выведенный тип выражения ys) будет равен List a (0 + m) (тип из сигнатуры). Разбирая конструкторы получим m == 0 + m, а это равенство у нас уже есть в определении (+).

Итак, вроде простая задача, но тут мы применили три приёма:
1. Подстановка (n == 0, m == n + m => m == 0 + m)
2. Разбор конструктора (декомпозиция? структурный декремент?)
3. Подстановка из равенства из определения функции (частный случай пункта 1, но из-за него нам надо знать определения функций над типами во время компиляции)

Пока не будем на этом останавливаться, поехали дальше.

Вторая часть определения

append (x:xs) ys = x : (xs `append` ys)

Откуда

x :: a
xs :: List a k
ys :: List a m
k + 1 == n
xs `append` ys :: List a (k + m)
x : (xs `append` ys) :: List a ((k + m) + 1)

Итак, мы должны сравнить List a (n + m) == List a ((k + m) + 1)
1. n + m == (k + m) + 1 (разбор конструктора)
2. (k + 1) + m == (k + m) + 1 (подстановка)
3. (k + m) + 1 == (k + m) + 1 (подстановка из функции)

Вроде бы пары приёмов - подстановки и разбора конструктора (эдакой эта-редукции уровня типов) нам хватает. На самом деле тут самое интересное. Допустим, что программист определил тип для append как List a n -> List a m -> List a (m + n). Т.е. рокировка n и m. Как тут будет проходить доказательство?

Для первой части имеем (после вытаскивания из конструкторов)

m == m + 0

А вот это доказать простой подстановкой уже не получается. Единственное, что пришло мне в голову использовать метод индукции. Проверяем для всех конструкторов типа Nat, начиная с простых (нерекурсивных, т.к. это data - они обязательно должны быть).

Для Z: m == 0, 0 + 0 = 0. ОК
Для S: m = k + 1
1. k + 1 == (k + 1) + 0 (подстановка)
2. k + 1 == (k + 0) + 1 (подстановка из функции)
3. k == k + 0 (разбор конструктора)
4. ОК (по индукции)

С индукцией тоже могут быть проблемы, о которых надо подумать: много переменных в равенствах, много параметров в конструкторах.

Тем не менее, мы получили три приёма - подстановка, разбор конструктора и индукция. Последние два, очевидно, никак не могут препятствовать проверке типа завершиться. Подстановка из функции - тоже, т.к. функции у нас терминируемы, только брать надо подстановки слева направо. Остаётся просто подстановка, из типа, выведенного из выражения и из типа, описанного программистом. Может ли здесь возникнуть такая ситуация, что в системе равенств будет присутствовать n = m + 1, m = n + 1? Если да, можем ли мы легко определять такие ситуации и грязно ругаться?

В общем, резюмирую.

Проверка типа заключается в доказательстве, что тип, описанный программистом является таким же или более конкретным, чем тип, выведенный из выражения в правой части. При доказательстве используются три приёма:
1. подстановка
2. разбор конструктора (может деструкция? надо в статьях посмотреть)
3. индукция

Проблемы возникают с подстановкой:
1. Надо знать содержание функций, применяющихся в описании типа.
2. Неясно как быть с подстановками, ведущими к нетерминируемости.

По первому пункту: видимо, надо знать именно равенства, а не паттерн -> case, разбирать проще. Правда, не представляю, как это может выглядеть.

Если у кого то есть материалы по теме, накидайте сюда плз - потом как руки дойдут обязательно прочту всё-всё-всё :-)

kind функционального типа

Wed, 23 Jan 2008 10:50:09 GMT

Prelude> :kind (->)
(->) :: ?? -> ? -> *

Дезинтегратор

Fri, 18 Jan 2008 10:11:32 GMT

Брат прислал: классная игрушка. 288 резинок - если не убьют, то закидают.

Вот видео оттуда:

почему я не хожу на выборы

Thu, 13 Dec 2007 08:45:13 GMT

Н. А. - Спасибо, понятно. А скажите, эта власть - демократична, как Вы оцените?

О. Д. - Куда уж демократичнее. Если, конечно, откинуть всякие сказки о демократии, якобы кто-то что-то решает, зайдя в кабинку для голосования. На самом деле кабинки существуют для того, чтобы население имело возможность туда заходить - торжественно, под звуки музыки. Это население должно надолго запоминать то, что они имели демократическую возможность поставить галочку в любом месте, где захотят. Это элемент стабилизации общественных процессов. Совершенно ясно, что экономика, крупный конкурентоспособный бизнес не могут пойти на такой великий риск - произвольное назначение менеджеров госаппарата, как бог на душу положит. Ни в одной западной стране нет такого произвола, а у нас на среднем уровне управления страной он некоторое время он был. Это сильно мешало власти и бизнесу. Теперь риск устранен, да и кадры отстоялись.

Не могу доказать :-(

Thu, 06 Dec 2007 11:57:36 GMT

Небольшое вступление.

Есть такой модуль Control.Applicative, в котором определён класс Applicative

class Functor a => Applicative a where
    pure :: a -> f a
    <*> :: f (a -> b) -> f a -> f b

т.е. он чуть шире Functor (за счёт pure), и чуть уже Monad. Золотая середина - полезно, когда нам от монад нужен только return.

Так вот есть такой метод: <**> :: f a -> f (a -> b) -> f b, который по сути представляет собой перевёрнутый <*>.
Однако его реализация в исходниках такая:

(<**>) = liftA2 (flip ($))

Я попытался привести это выражение к flip (*) и вот что у меня получилось:

liftA2 (flip ($))
\a b -> (flip ($)) <$> a <*> b -- definition of liftA2
\a b -> (fmap (flip ($)) a) <*> b -- definition of l<$>
\a b -> (pure (flip ($)) <*> a) <*> b -- Functor instance rule: f `fmap` a = pure f <*> a

В это месте у меня затык. Предположив, что a = pure a' можно получить

\a' b -> (pure (flip ($)) <*> pure a') <*> b -- a = pure a'
\a' b -> pure (flip ($) a') <*> b -- homomorphism rule: pure f <*> pure x = pure (f x)
\a' b -> pure ($ a') <*> b -- flip ($) x = ($ x)
\a' b -> b <*> pure a' -- interchange rule: u <*> pure y = pure ($ y) <*> u

Ну и возвращая a на место вместо a'

\a b -> b <*> a
flip (<*>)

ЧТД. Но! Я совершенно не уверен, что могу делать допущение подобное a = pure a'.
Кто нибудь подскажет, как выровнять доказательство?

FYI I am a spy ;-)

Tue, 06 Nov 2007 09:49:26 GMT

Давно ничего не писал, обновлю журнал.

Вот парень классно прикололся.

Пробежал позавчера HL2E2. Атака страйдеров отражается так - убиваешь охотников машиной, при этом у тебя скорее всего будут тяжёлые потери, но охотник валится сразу; либо гравипушкой закидываешь их какашками - так ты более мобилен и сил для игр и роста остаётся гораздо гораздее. Дальше просто - бомбу-липучку к пузу и биг-бада-бум!! Ах да! Ещё я бомб вокруг себя побросал, чтобы их не ждать в телепорте.

Горилла в чувствах-с

Mon, 15 Oct 2007 10:47:19 GMT

Просто балдею. Уже несколько раз поглядел.

Опять про Monadability

Thu, 12 Jul 2007 08:51:56 GMT

Допустим у нас есть тип (X a), где X ::= T x y z ... Тут важно, что "a" последнее.
Тогда если "a" хотя бы в одном конструкторе данных стоит слева от стрелки, то этот тип нельзя сделать функтором (instance Functor) так, чтобы соблюдались законы над функторами, нес па?

Кстати!

Wed, 04 Jul 2007 14:57:27 GMT

Для equational reasoning в Haskell можно (иногда нужно) пользоваться GHC Rules (На Haskellwiki), чтобы написанное было читабельным и maintainable, а скомпилированное эффективным. А для нахождения нужных правил можно воспользоваться Theorem for Free. Например, его автоматической выводилкой. Или использовать free / ft команды lambdabot-а.

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

Это я всё мечтаю. Нарисовал нужные типы данных, сформировал по ним типы функций для работы над ними, автоматически построил их реализацию, автоматически построил правила, выбрал нужные для оптимизации. А дальше работаешь легко и непринуждённо. Это идеал, разумеется. Но я уверен, что частично эту работу можно автоматизировать. Типа того, что при доказательстве Coq'ом ему надо указывать стратегии, так же и здесь при реализации тела функции надо направлять "думатель".

Это вообще возможно? А то у меня каша в голове.

Токипона: ссылки

Tue, 26 Jun 2007 13:29:52 GMT

Официальный сайт токипоны.

Уроки токипоны:

^[RUS]Токипона на wikibooks (переведённые от jan Pije). Классика. Учитесь по этим урокам.
^[RUS]Уроки от jan Lekalo. Это даже не уроки. Парень учит токипону и по ходу обучения рассказывает про неё. По моему первый обучающий ресурс на русском.
^[RUS]Уроки на лингвисто от jan Eliki. Неоконченные, но проникнутые духом токипоны. Есть красивая азбука от Lament.

Общества, группы и т.д.

WIKI на TP.
TP на LJ.
^[RUS]TP на русском LJ.
TP группа на yahoo.

Персональные странички

jan Pije. Тексты, картинки, музыка. Есть сценарий "В поисках священного Грааля" Монти Пайтона.
jan Jakopo. Частота употребления звуков. Панграммы.
jan Ke. Гимны, молитвы.
Потом допишу, неохота вспомнить.

Письменность

Тенгвар
Скоропись или что то вроде этого. Не помню.
Хангыл. Самое симпатичное по мне. Сэмпл.
Иероглифы. Прикольно.
Иероглифы неоконченное

Послушать, посмотреть

shinan с 9:22 до 13:41 прикольно так болтает.
Песенки от Pije
Ещё где то лежало "mama pi mi mute o". Что то не найду сходу.

mi jo e jan lili

Mon, 25 Jun 2007 09:05:03 GMT

А у #tokipona дня три такой топик:

jan Lome li jan pi toki pona. ona li jo e jan lili sin. ona li mije. pona!

приятно чёрт возьми :)

Fri, 22 Jun 2007 06:55:37 GMT

Это ж надо умудриться родиться в самую короткую ночь в году!
Теперь у меня два рака. Когда подрастут, буду пить пиво с раками.

Опять про паттерн матчинг

Mon, 18 Jun 2007 13:13:27 GMT

На RSDN технические работы.

Хотел зацепиться в очередном флейме "ФВП vs паттерн-матчинг". Ребята показывали насколько ПМ сокращает код и проясняет его по сравнению с обычным императивным. А я пытался показать, насколько комбинаторы сокращают код и проясняют его по сравнению с ПМ. Ну и заодно показал пример как на основе equational reasoning можно улучшить код.

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

Изначально, стояла такая задача (если я её верно понял):

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

Вообще то это подзадача, вторая подзадача там была - получение init списка, его тоже зачем то решали через ПМ (в Немерле нет аналога init?).

Вот решение на Немерле с использованием паттерн-матчинга:

def GetDx(_, _)
{
| ([ck], [cf]) =>
    cf.Map(_ * ck)
 
| (ck :: klast, cf :: flast) =>
    def incDx = GetDx(klast, flast);
    cf.MapI((i, f) => f * ck + incDx[i])

| _ => throw Exception();//Если списки разной длинны.
}

Удалены участки, относящиеся к вычислению init. MapI - это map с дополнительным параметром - индексом. Матрица в решении - это не список списков, как у меня на Haskell, а список массивов, так что MapI применим, правда, по мне всё таки zipWith (\x y -> ck * x + y) cf incDx понятнее.

Вот первое пришедшее мне в голову решение на Haskell.

getDx ks fs = map sum $ transpose $ zipWith (\x -> map (x*)) ks fs

zipWith (\x -> map (x*)) ks fs - переменожаем ks на столбцы fs
map sum . transpose - суммируем столбцы

Плюс, помимо краткости и выразительности: мы можем легко сделать преобразования.

Сделать их можно, используя три закона

1. (f . g) . h == f (g . h)

2. map f . map g == map (f . g)

3. transpose . zipWith (map . f) xs == map (zipWith f xs) . transpose

а также эта-редукцию и замену ($) на (.)

Всю цепочку показывать не буду - она тривиальна. Вот результат:

map (sum . zipWith (*) ks) $ transpose fs

По моему короче, эффективнее и понятнее. Внутри сразу видно маленькую чётко очерченную подзадачку (sum . zipWith (*) ks) - вектор на вектор, результат сложить. В случае паттерн-матчинга эта подзадачка раскидана по всему коду; сделать преобразование, подобное приведённому, гораздо сложнее.

P.S. А ещё я сегодня видел в метро парня, читавшего распечатку "Знакомство с языком Haskell" или что то в этом духе ;-)

P.P.S. А ещё я подумал, что изобрёл слово "индексикация" как перевод indexitis (болезнь использования (!!) в Haskell), а оно оказывается существует реально и означает совсем-совсем другое :-(

Про лямбду, как всегда.

Fri, 08 Jun 2007 13:23:04 GMT

Удивительно быстро прошёл Episode One

Жду - не дождусь Episode Two

А ещё я всё это могу играть, потому что у меня сгорел компьютер, и я взял новый.

Задачка со свёрткой

Mon, 21 May 2007 11:50:05 GMT

Читал статью Bernie Pope "Getting a Fix from the Right Fold" из The Monad. Reader Issue 6. В ней решается задачка о написании dropWhile через foldr. В частности, эта задачка решалась в Graham Hutton "A Tutorial on the Universality and Expressiveness of Fold" через таплы.

У меня удивительно быстро получилось решить эту задачку. Решение было эквивалентным решению 2 в статье.

Смысл в том, чтобы породить функцию с помощью foldr, которую мы уже затем применим к списку. Функция или вернёт тот же список или обрежет у него хвост, т.е. id (tail (tail (tail (tail (tail xs))))).

myDropWhile p xs = foldr f id xs xs
    where
        f x g xs | p x       = g (tail xs)
                 | otherwise = xs

К сожалению, это решение неоптимально, т.к. функция, порожденная foldr (та самая к которой мы второй раз применяем список), зависит от количества сброшенных элементов. Pope предлагает решение, которое вместо порождения цепочки функций, попеременно применяет функцию к списку. Для этого достаточно, чтобы tail был вызван раньше g, который является рекурсивным вызовом foldr. С помощью паттерн-матчинга (который как известно неленив) мы получим:

myDropWhile p xs = foldr f id xs xs
    where
        f x g xs@(_:ys) | p x       = g ys
                        | otherwise = xs

Я бы не догадался. Мне пришлось бы расписывать пример, как проходит вычисление, чтобы до этого дойти. Как он это сообразил, не пойму... Он то, конечно, говорит, мол, Эврика! и всё такое...

Team Fortress 2 (персонажи)

Thu, 17 May 2007 11:54:34 GMT

Team Fortress 2

Thu, 17 May 2007 11:53:04 GMT

Functional pearls

Mon, 07 May 2007 14:25:07 GMT

Недавно на 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.

Натуральные числа и Нео

Thu, 03 May 2007 14:17:37 GMT

Тут подумал, что thesz в рамках

data Nat = Z | S Nat

читается как The (S Z), т.е. The One.

Давно я ничего не писал, поэтому напишу хоть что нибудь.

Wed, 02 May 2007 12:41:20 GMT

Одной из поразивших меня вещей в ФП был Curry-Howard изоморфизм.

Вывод типов всегда завершается, говорите?

Tue, 10 Apr 2007 10:23:19 GMT

Вот здесь у меня висит на выводе типа myFix:

newtype Fun a = Fun (Fun a -> a)
 
fun x@(Fun f) = f x
 
myFix = fun (Fun fun)

Запускал в GHCi 6.6