Вышел Glasgow Haskell Compiler 7.10.1

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

Пример злостного сжатия: http://hackage.haskell.org/package/base-4.7.0.1/docs/src/Data-List.html#permu...

permutations            :: [a] -> [[a]]
permutations xs0        =  xs0 : perms xs0 []
  where
    perms []     _  = []
    perms (t:ts) is = foldr interleave (perms ts (t:is)) (permutations is)
      where interleave    xs     r = let (_,zs) = interleave' id xs r in zs
            interleave' _ []     r = (ts, r)
            interleave' f (y:ys) r = let (us,zs) = interleave' (f . (y:)) ys r
                                     in  (y:us, f (t:y:us) : zs)

Пример злостного сжатия

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

Скучно... Тролли! Хотите еды — извольте поработать.

По-моему, тут все прозрачно. Приведите пример того же алгоритма, но как надо?

А зачем? Вы никогда что-ли не видели как алгоритмы пишутся в императивном стиле? Если видели, то вот. Если нет, то вам этот разговор стоит отложить на некоторое время.

не продвинувшийся дальше вбивания примеров из туториалов в GHCi.

http://evgenijm86.livejournal.com/3098.html

Уважаемый, Евгений, не могли бы вы подробно объяснить о что конкретно помешало вам записать этот алгоритм в императивном (или похожем на нем) стиле. Это так для того чтобы было понятно, что разговор можно начинать..

Мне конкретно сейчас помешало то, что мне не было никакой нужды переписывать этот конкретный алгоритм из библиотеки Haskell на императивный стиль. Вот не встаю я по утрам и не переписываю на угад алгоритмы из библиотек одного языка в другой. Такой вот я странный человек. И ради анонимного комментария я тоже это делать не буду.

http://evgenijm86.livejournal.com/3098.html

К тому же, еще и питонщик.

К тому же, еще и питонщик.

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

Такой вот я странный человек

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

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

И дело тут не в реализации и даже не в алгоритме, а в том, что мне для его чтения надо постоянно скакать из одного место в другое, как будто читая goto метки. Это не удобно, хотя и коротко. На Haskell замечательно писать, но не удобно читать - вот и вся моя мысль.

мне просто там понравился синтакс обхода массива

Не различаем массивы и списки? Бывает!

Вообще-то в хаскеле есть точно такая же штука. Но для списков, понятно дело и со слегка другим синтаксисом.

Массивы же в хаскеле — совсем другая песня.

На Haskell замечательно писать, но не удобно читать - вот и вся моя мысль.

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

будут тащить что попало (в смысле качества).

А чем тебе качество-то не угодило? Всё нормально с качеством. Только не подходит данное решение для реальных задач когда надо много и быстро.

Только не подходит данное решение для реальных задач когда надо много и быстро.

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

Понимаете, дело в том, что данный алгоритм, это скорее всего не-тот алгоритм императивный алгоритм, про который говорите Вы. Но проверить это невозможно, т.к. пока тут была только копипаста из base невозможно, без каких-нибудь пояснений ваших мыслей. Поэтому я предложил Вам описать своими словами, что вам помешает написать так, как бы это хотелось. Ответ на этот простой вопрос позволил бы понять насколько вы понимаете предмет и понять откуда стоит начинать ответ. Поскольку продолжаются отговорки, то можете просто поверить, что представленный алгоритм просто не является «сжатием» привычного Вам императивного алгоритма.

Вот не встаю я по утрам и не переписываю на угад алгоритмы из библиотек одного языка в другой.

Вам этого никто не предагал.

И ради анонимного комментария я тоже это делать не буду.

да, я согласен, не мешало бы вам представиться :)

ты можешь предложить более эффективную перестановку simple linked list? =)

Вот такой вариант - отрываем голову, получаем перестановки для хвоста и вставляем голову во все возможные позиции.

permute :: [a] -> [[a]]
permute [] = [[]]
permute (x:xs) = concatMap (\h -> interleave h x []) (permute xs)
    where 
        interleave [] x ts = [x:ts]
        interleave hs x ts = [hs ++ (x:ts)] ++ interleave (tail hs) x ((head hs):ts)

Интересует такой вопрос: как сейчас акселерейт в сравнении с репой в плане качества имплементации?

Сорри, не в курсе. Я на хаскеле занимаюсь быдлокодингом: распарсить там чего-нибудь, запилить веб-сервис с JSON и шлюхами, что-нибудь по FFI подёргать... С числодробилками я дел не имею.

ты можешь предложить более эффективную перестановку simple linked list? =)

Нет. Я только про то что при больших размерах списка permute будет тормозить и генерить тонны мусора.

Хотя, с другой стороны... Я вон файлы по 500к парсеком из String ([Char] для тех кто не в курсе) разбираю. И ничё, терпимо так... А за пару лет работы эта штука спасла несчётное количество моих неврных клеток, и не только моих... Потому что неоднократно убирала дерьмо за вышестоящей всей-такой-ынтырпрайз системой, когда она позорно обисралась.

ты можешь предложить более эффективную перестановку simple linked list? =)

Кстати, как я правильно понимаю что в реальных задачах лучше пермутить не контейнер, а соответствующую монаду?

сорри, я не понимаю, что такое «пермутить соотвествующую монаду»..

Список это тоже монада.

или сделать типа "моноидов на верёвках"

и вообще вырисовывается теоркатегорная СУБД с логической моделью данных через монады и запросы катаморфизмами (а данные — в деревьях на которых задана мера моноида).

ты можешь предложить более эффективную перестановку simple linked list? =)

суперкомпиляцией: сразу CTFE сгенерировать исходник как последовательность операций, то есть, список выражений, то есть, монаду. то есть делать все вычисления во время компиляции при запросах через «моноиды на верёвках» и сразу генерить самое оптимизированное, эффективное.

просто перестановки это тоже моноид (см. статью про инкрементальные регэкспы с примером такого моноида), в монаде перестановок.

или сделать типа «моноидов на верёвках»

О! Круто! Каюсь, о фпрог.ру я напрочь забыл. Надо обязательно перечитать.

А ради неанонимного комментария? Ведь правда интересно увидеть элегантное решение! Расчет К-means это, конечно, круто, но хотелось бы по-существу.

Ну т.е., EvgenijM86, ты проблеял возразил и позорно слислся ограничился отговорками?

вообще: кажется, что тот же MUMPS, например, — это СУБД, где логическая модель данных это M-кубы, а физическая — это BTree (и индексы — это строки) — это по сути частный случай «верёвок, измеримых моноидами». когда моноид — это конкатенация строк, единица моноида — пустая строка, а верёвка — это BTree с перебалансировкой.

тогда более другие СУБД — это общий случай верёвок и деревьев типа finger tree, с более другими моноидами.

интересен конечно случай, когда можно задавать запросы или pretty printing катаморфизмами и вообще задавать в СУБД модели соответствующие монадам, категориям или топосам Гротендика.

то есть, использовать тот факт, что на основе теории категорий задаётся «уравнение в морфизмах» (в этом смысле например, инварианты, то есть законы сохранения вида интеграл от блаблабла = 0 можно переформулировать как интеграл это произведение цепи на коцепь и далее расписать для дифференциала функции и дифференциала аргумента где там цепь, где коцепь и какие там монады с морфизмами; тоже для производных и в общем, групп, а не просто монад; пространство это кольцо функций).

и набрать базу знаний для известных «уравнений в морфизмах» и инвариантов.

тогда подобная теоркатегорная СУБД позволит переносить свойства аксиом (конструкторов в категории) и теорем (функторов в категории) между различными частными науками — например, аналогично тому как топосы Гротендика позволяют переносить между когерентными теориями.

или, переносить между различными моноидами с разными мерами. получается что-то типа «моноида(?топоса) на верёвках, измеримых моноидами».

было бы прикольно поковырять такую вот «теоркатегорную СУБД», ага.

Пример злостного сжатия: (...)

Любой из вариантов по ссылке короче библиотечного. В бибилотеке оно такое не ради «сжатия».

Нет. Я только про то что при больших размерах списка permute будет тормозить и генерить тонны мусора.

Почему это?

там следующий после хаскеля язык, Icon/Unicon тоже достаточно упоротый интересный: с ковыражениями и корутинами, и goal-directed computing, вот это всё. ЕМНИП noweb какой-то версии был на Icon написан.

Для прикола даже коммит нашёл: https://git.haskell.org/ghc.git/commitdiff/02c91df7881fe2a416e4e2b64f29d45b54...

'permutations' is now more lazy and also faster

Так как по-твоему сделать permutations быстрее-выше-сильнее? Роди^WОпенсорсу нужны герои.

К тому же, еще и питонщик.

Фу какая мерзость.

Загляни сюда http://ruby-doc.org/core-2.2.0/Array.html#method-i-each. Сразу станет очевидно, что for просто не нужен и нелеп.

Копаться в стандартной библиотеке есть смысл всегда для того что бы: а) оценить качество платфомы; б) обучиться эталлоному стилю разработки для данной платформы.

а) оценить качество платфомы; б) обучиться эталлоному стилю разработки

И оба раза мимо. Где угодно, только не в base, там либо вот такая вот примитивщина, запиленная на ранних стадиях без каких-либо обоснований вообще по желанию левой пятки, либо лютые GHCизмы в которых без бутылки не разберешься.

Его давно пора разделить на части, но во-первых, это неподъёмная задача, а во-вторых, всем пофиг. Попытка запилить пакет haskell2010 (который всё-равно тащил за собой base) популярности не снискала, что неудивительно.

split-base движется но медленно :)

P.S. в примере выше не примитивщина, если что..

в примере выше не примитивщина, если что..

Ну, наверное лучше различать понятия «тривиальный» и «примитивный». Прмитивный, это значит что в большинстве случаев можно использовать как неделимый строительный блок без особой нужны разбираться как оно внутри устроено.

> а) оценить качество платфомы; б) обучиться эталлоному стилю разработки

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

А обоснования к примитивщине нужны? Чем она плоха? Почему является плохим примером?

либо лютые GHCизмы в которых без бутылки не разберешься.

Примеры?

Примеры?

Ну открой исходники и посмотри. Можно и онлайн, бесплатно и без СМС. Даже беглый просмотр иерархии модулей позволяет сразу определить где примитивщина, а где GHCзмы.

Фишка base в том, что для разработки base нельзя использовать ни один «внешний» пакет... Потому что они *все* от него зависят.

Даже text, даже bytestring, даже stm, async и io-streams. Вот и прикинь какие сложности встают перед теми кто пытается создать (или изучить), например, IO-manager...

Давно уже пора разделять на несколько пакетов по принципу: чистые функции, низкоуровневые механизмы, высокоуровневые реализации и т.д. Но, это реально неподъёмная задача, да и пофиг всем.

Поэтому, base — это *совсем* не тот пакет с которого нужно начинать знакомство.

Мне не понравилось то, что он позволяет множество алгоритмов записывать в сильно сжатой форме.

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

Ну открой исходники и посмотри. Можно и онлайн, бесплатно и без СМС. Даже беглый просмотр иерархии модулей позволяет сразу определить где примитивщина, а где GHCзмы.

А сам - не? :]

Фишка base в том, что для разработки base нельзя использовать ни один «внешний» пакет...

Никак не противоречит тому, что base - нормальный пакет для обучения.

Потому что они *все* от него зависят.

Естественно, он реализует (и всегда реализовал) функции и модули из стандарта haskell. Точно так-ж,е как C программы зависят от libc.

Вот и прикинь какие сложности встают перед теми кто пытается создать (или изучить), например, IO-manager...

Никаких? IO manager лежит в libraries/base/GHC/Event/ и в rts/posix/Select.c.

Давно уже пора разделять на несколько пакетов по принципу: чистые функции, низкоуровневые механизмы, высокоуровневые реализации и т.д. Но, это реально неподъёмная задача, да и пофиг всем.

Зачем?

Поэтому, base — это *совсем* не тот пакет с которого нужно начинать знакомство.

Это ни из чего не следует :]

Мне тоже не понятно. Не мог бы развернуть ответ?

Конкретно - с чего лучше начать обучение, если не с base?

Точно так-ж,е как C программы зависят от libc.

Не точно также! А точно так же как раньше программы зависели от Qt3. В Qt4 ввели модульность, в Qt5 — продолжили.

Естественно, он реализует (и всегда реализовал) функции и модули из стандарта haskell.

Бху-га-га-га! Кто сказал что стандарт языка должен быть реализован в одном модуле? Тем более, когда есть по крайней мере чёткое разделение на pure-impure?

Мне тоже не понятно. Не мог бы развернуть ответ?

Что именно не понятно?

Я написал выше: «Конкретно - с чего лучше начать обучение, если не с base?»

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

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

с чего лучше начать обучение, если не с base

attoparsec - aeson - scotty. Если бы я кого-то бы обучал, то построил бы курс вокруг этих пакетов.

1. Можно писать реальные (tm) программы.

2. Покрывается достаточно большое количество идиоматики.

3. Относительно несложно.

спасибо.

А каково твое мнение о Hakyll? Я пользуюсь на уровне ковыряния html темплейтов и редактирования маркапов для содержания. В код особе не лез - для говнобложика не требуеся. Пока все устраивает.

А каково твое мнение о Hakyll?

Никогда не пользовался. Без разницы, на самом деле. Куда бы ты не лез, а путь-то один... Сегодня играешься с маркапом для хакила, а завтра куришь дикие теоретические статьи.

И да... Если тебе некомфортно каждый день ощущать жалким, никчёмным, тупым ничтожеством — причём, чем дальше ты будешь двигаться по дао тем сильнее будет чувство — то хаскель не для тебя.

Два раза в год это чувство достигает эпических величин, т.к. два раза в год выходит HCAR. Чтиво не для слабонервных.

ты так говоришь «ощущать жалким, никчёмным, тупым ничтожеством», как буд-то это что-то плохое. HCAR не курил, спасибо за наводку.

> Естественно, он реализует (и всегда реализовал) функции и модули из стандарта haskell.

Бху-га-га-га! Кто сказал что стандарт языка должен быть реализован в одном модуле?

А в base и не один модуль.

Примеров плохого кода base не добиться. Ладно, будем обсуждать «модульность».

Тем более, когда есть по крайней мере чёткое разделение на pure-impure?

Предлагаю ответить на каждую строку: «pure» или «impure» (что бы это не значило :])

sequence :: Monad m => [m a] -> m [a]
error :: [Char] -> a
seq :: a -> b -> b
class IO ...
class [] a ...
class Maybe ...
class Monad ...
class Monoid ...
instance Monad IO ...
instance Monad Maybe ...
instance Monad [] ...

Если тебе некомфортно каждый день ощущать жалким, никчёмным, тупым ничтожеством — причём, чем дальше ты будешь двигаться по дао тем сильнее будет чувство — то хаскель не для тебя.

Какие дешёвые понты, позорище.