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

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

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

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

Читал статью 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 в статье.

( Подглядеть )

Начинается
Эх, deni_ok, что же ты наделал! :-)

Сегодня читал в ru_declarative вопрос и уже на предложении

Можно ли ещё более "закомпрехенсить" list comprehensions?

понял, что человек спрашивает про sequence. Штампы, однако!.. Ну, или темплейты там, паттерны...

Когда мы пишем монадическую функцию с хвостовой рекурсией, то явно эта функция не хвостато-рекурсивная:

loop = do
    cmd <- getLine
    if (cmd == ":q")
        then return ()
        else loop

( чуть-чуть кода и много вопросов )

Наконец то! SPJ предлагает добавить views patterns в Haskell'.

Views patterns - это не совсем views, вернее, совсем не views :-) Это, скорее, другая форма записи pattern guards - более легкая и почти элегантная ;-) Здесь SPJ ещё в далёком 97-м рассматривал pattern guards как альтернативу views.

Мой интерес к views растёт с одной задачи, которую рассматривали мы с thesz. Ниже я описал pattern guards как раз на её примере.

( чуть подробнее )

Неожиданно обнаружил, что при включенном -fglasgow-exts для newtype можно делать deriving любых классов, экземпляром которого уже является обернутый тип.

newtype Stream a = S [a]
    deriving (Functor, Monad, Show)

А я дурак сижу пишу инстансы.

UPD: Читайте ещё извращений про deriving. На моём 6.4.2 не работают.
UPD 2: А вот и описание этой фичи.

Хорошая статья про монад-трансформеры для тех, кто ещё не понимает как с ними работать:
Monad transformers step-by-step

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

При dynamic scoping за связывание переменной отвечает вызывающий код, а не вызываемый.

Пример

function foo()
{
    print x; // x имеет динамическую область видимости.
}

function bar()
{
    var x = 5;
    foo(); // вот здесь x и привяжется.
}

( то же самое на Haskell )

Только сейчас сообразил, что это одно и то же для ВСЕХ монад.
До сих пор думал, что они совпадают у IO и списка.

А вот дефолтную реализацию метода класса, от которого зависит определяемый класс, нельзя описать. А то можно было бы

class Functor m => Monad m where
    return :: m a
    (>>=) :: m a -> (a -> m b) -> m b

    instance Functor m where
        fmap f m = m >>= (return . f)

Ну и хорошо, что нельзя. А то от Functor много классов могут зависеть.