Победил HXT, вынув из XML'ек условия задач для рассчётки. Всё ещё не понимаю, как может стрелка иметь тип ArrowXml a => a XmlTree XmlTree и при этом возвращать не одно значние, а несколько. Не понимаю, как это всё разветвляется и сливается обратно без необходимости делать map и concat. Аргх.

--Minoru, который думал, что он понял стрелки

Драйвер редиса возвращает Redis (Either Reply a). При операции HGET возвращает, соответственно, Redis (Either Reply (Maybe ByteString)), типа значения по ключу может и не быть. Программист для упрощения пишет сначала специальную функцию redis', которая заворачивает ответ редиса в EitherT-based монаду, чтоб соединять подобные вычисления и возвращать первую неудачу:

newtype Redis' a = Redis' (EitherT Redis.Reply Redis.Redis a) deriving (MonadIO)
instance Monad Redis' where
    return = Redis' . EitherT . return . Right
    (Redis' m) >>= f = Redis' $ m >>= \rv -> unwrapRedis' $ f rv
redis' = Redis' . EitherT

Таким образом, теперь, если вы получаете ответ Redis (Either Reply a), вы его преобразуете в

Redis' (EitherT Reply Redis a)

и можете соединять подобные вычисления в do-блоке типа:

do
    res <- redis' $ Redis.hget foo bar
    res2 <- redis' $ Redis.hget baz zab

и вычисление остановится на первом возврате ошибки.

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

newtype HashFields a = HashFields (MaybeT Redis' a)
    deriving (Functor, Monad)
instance Applicative HashFields where
    pure = return
    (<*>) = ap

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

hashField = HashFields . MaybeT . redis'

способная завернуть результат неудачи в новую монаду, которая умеет останавливаться на первой неудаче. Также пишется специальная функция для HGET:

getField :: ByteString -- ^ Key
         -> ByteString -- ^ Hash field name
         -> HashFields String
getField key field = fmap toString $ hashField $ Redis.hget key field

Также напишем функцию, которая "запустит" наше вычисление:

getRedisFields :: forall a. HashFields a -> Redis' (Maybe a)
getRedisFields (HashFields f) = runMaybeT f

И теперь лёгким движением руки мы можем сделать что-то вроде:

getRedisFields ((,,,,,) <$>
    getField k "foo" <*>
    getField k "bar" <*>
    getField k "baz" <*>
    getField k "zab" <*>
    getField k "rab" <*>
    getField k "oof")

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

Какая XMPP-либа нынче наиболее пригодна для реализации XMPP-based протокола (Infinote)?

[22:29:29]<L29Ah_> haskell way: библиотек нет, а те, что есть, сделаны в трёх несовместимых инкарнациях
[22:30:16]<L29Ah_> какой в платформе сорт кондуитов и линз?
[22:30:44]<qnikst> никакого
[22:30:51]<qnikst> и не будет

http://stackoverflow.com/users/570689/

Опубликовал мюслекалькулятор: https://github.com/l29ah/muesli
Patches are welcome!

А поясните мне за песочницы: разве они не должны наследовать пакеты, установленные в системе и у пользователя?

Я почему спрашиваю: pandoc-1.9.4.5 не собирается в sandbox (похоже, там кто-то захардкодил пути и sh не может найти какой-то файл), так что я поставил его под юзером (то есть в ~/.cabal). Но после того, как я делаю cabal sandbox init, cabal list pandoc утверждает, что установленных версий pandoc нет. Я что-то делаю не так, или я чего-то не так понял?

Как на хаскеле создать DSL, если haskell не умеет в расширение и изменения синтаксиса языка? Поясните по хардкору.

Считаете, что монадные трансформеры это сложно?

Попробуйте разобраться с syntax model в racket!

Нас было 7 человек. У нас было 20 модулей на хаскеле, приватный репозиторий на гитхабе, 6 веток в этом репозитории, ImplicitParams, MagicHash и UndecidableInstances в коде и одна highmem нода на амазоне, а также hangouts для общения, юнит-тесты, просто тесты, google docs для заметок и куча статей про SMT-солверы.

$ torify cabal update
Downloading the latest package list from hackage.haskell.org
Segmentation fault

Кстати, надо бы наверное сделать специальный обфускатор для хаскеля. Работать он будет так:

1. сперва пишем обычный, нормальный код.

2. автоматически заменяем все имена на бессмысленные f, g, x etc.

3. у нас получается некоторое дерево вызовов, проводим замену его поддеревьев по определенным rewriting rules, например дерево (f x) на f $ x, f (g x) на (f . g) x, то что сделал ты с f $ g <*> h и т.п., потом проводит «депоинтизацию», убирая где можно аргументы.

Ну то есть делаем то, что сделал ты. Только автоматически. И с этого моменты хаскелисты перестают быть нужными — т.к. весь их арт оказывается легко и непринужденно может быть исполнен автоматическим обфускатором.

ЗЫ: обрати внимание на первый пункт — получить обфусцированный код можно только тогда, когда нормальный код уже есть. Это к слову о любителях ненужной работы.

ghc doesn't fuse lists (avoiding success at all costs?)

http://stackoverflow.com/a/17345377/2350060

https://research.microsoft.com/en-us/um/people/simonpj/papers/ndp/haskell-beats-C.pdf

Abstract
Stream fusion [6] is a powerful technique for automatically transforming high-level sequence-processing functions into efficient implementations. It has been used to great effect in Haskell libraries for manipulating byte arrays, Unicode text, and unboxed vectors. However, some operations, like vector append, still do not perform well within the standard stream fusion framework. Others, like SIMD computation using the SSE and AVX instructions available on modern x86 chips, do not seem to fit in the framework at all.
In this paper we introduce generalized stream fusion, which solves these issues. The key insight is to bundle together multiple stream representations, each tuned for a particular class of stream consumer. We also describe a stream representation suited for ef ficient computation with SSE instructions. Our ideas are implemented in modified versions of the GHC compiler and vector library. Benchmarks show that high-level Haskell code written using our compiler and libraries can produce code that is faster than both compiler- and hand-vectorized C.

На ассемблере такие вещи надо делать. Алсо, тут http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=gcc&lang2=ghc&data=u64q хаскель сливает сишке почти по всем пунктам. И я бы не сказал, что кода на х-е сильно меньше, чем кода на Си

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

Товарищи, я тут в жуйках итд вижу много вопросов по хаскелю, как разрулить ту или иную проблему итд.

Так это, хаскеллисты, расскажите над какими проектами вы вообще работаете?

Ну чо, кто готов?

A solid background in computer science, documented experience and/or strong academic education in advanced functional programming in Haskell are assumed. Knowledge of type systems, Martin-Löf type theory, dependent types, formal methods, static analysis, MSR Code Contracts, hardware verification, HDLs, Spec#, Coq, Agda, Idris, Epigram, Twelf or other similar tools, languages, theorem provers is desirable but not required. Knowledge of parsing, skills also in other programming languages including experience from C, C#, C++, Objective-C and also Scala, is also desirable but not required. Higher academic degrees such as a PhD in computer science are not required but certainly taken into account. Entrepreneurship skills or industrial experience is not required here – but if such exists it is considered to be a strong merit as well. Knowledge in UNIX and Linux is required. Finally, experience from using Visual Studio, Eclipse or other IDEs is relevant.

@qnikst на Juick предлагает коллективно разобрать книгу «Purely Functional Data Structures» Окасаки. Присоединяйтесь! http://juick.com/2339137

Часто слышу следующие доводы за сабж:

• Статическая типизация - тесты не нужны.
• Иммутабельность данных - организация concurrency превращается в тривиальную задачу;
• Благодаря сигнатурам функций не нужна документация;
• Если где-то при рефакторинге поменять тип, то компайлер покажет где еще чо нужно поменять, чтоб программа собралась, PROFIT;