Классно

https://github.com/Frege/frege

Не было, Денис вот только выложил

Из оглавления шикарный фарш компилируется

УДОБНЫЙ СПОСОБ БРОСАЕМ ЧАСТИЧНОЕ ПРИМЕНЕНИЕ ФУНКЦИИ БОЛЬШЕ СПИСКОВ ГОТОВИМ СТРУКТУРУ КОНСТРУКТОР ТИПА ВМЕСТЕ ДОБАВЛЯЕМ ПРЕДИКАТ А ВОТ КАК В HASKELL ПОЧЕМУ ИХ ТАК БОЯТСЯ ЛЮБОЙ, ДА НЕ СОВСЕМ О МОДУЛЯХ, МИНИМУМ СПИСКИ — ОДНИМ ВЗГЛЯДОМ КОНСТАНТЫ БЕЗ ОБЪЯВЛЕНИЯ СОБСТВЕННЫЙ ТИП ЭКЗЕМПЛЯР КЛАССА ТИПОВ ЗАКЛЮЧЕНИЕ МОНАДЫ: ПРАКТИКА MAIN ДЕЛИКАТЕСЫ ОДИН КОНСТРУКТОР ЗНАЧЕНИЯ ДОБАВЛЯЕМ В ПРОЕКТ О КОНСТРУКТОРАХ ЗНАЧЕНИЙ О ФОРМАТИРОВАНИИ ОЛЬЗОВАТЕЛЬСКИЕ ТИПЫ ЧИСТЫЕ ФУНКЦИИ ИНЫЕ ИМЕНА EQ ПЕРЦЫ ИЩЕМ СТАНДАРТНЫЕ ВВОД И ВЫВОД МОНАДЫ: СУТЬ МНОЖЕСТВЕННОСТЬ УСТАНАВЛИВАЕМ СОВМЕСТНАЯ РАБОТА ЛЕНЬ ЗАПУСКАЕМ О ФУНКЦИЯХ СОБСТВЕННЫЕ ИСКЛЮЧЕНИЯ ОБ ИЕРАРХИИ BOUNDED ПОГРУЖАЕМСЯ ЧТО С НИМИ МОЖНО ДЕЛАТЬ ЧТО С НИМИ МОЖНО ДЕЛАТЬ МНОЖЕСТВО АРГУМЕНТОВ НАСТРАИВАЕМ СОЗДАЁМ СВОЙ ОСТАЛЬНОЕ ЛОВИМ ПРО АПОСТРОФ О HACKAGE READ КИТ ТРЕТИЙ ФУНКТОРЫ ЕЩЁ И МОНАДА MAIN КАКАЯ ОТ НИХ ПОЛЬЗА ПРОБЛЕМА С ФАЙЛОМ ВСЁ, КРОМЕ МОНАДЫ: НА ПРИМЕРЕ IO УПОМИНАЕМ ЧИСТАЯ ФУНКЦИОНАЛЬНОСТЬ НОВЫЙ ТИП RETURN САМА СЕБЯ ФУНКЦИОНАЛЬНЫЕ ЦЕПОЧКИ МНОЖЕСТВО КОНСТРУКТОРОВ НАСЛЕДУЕМ РАЗБИРАЕМСЯ ОБЯЗАТЕЛЬНАЯ ПРИНАДЛЕЖНОСТЬ ЗАЧЕМ ЭТО НУЖНО ДОБАВЛЯЕМ УСЛОВИЕ СОЗДАЁМ ПРОЕКТ УСЛОВИЕ ENUM О ФУНКЦИИ ВСПЛЫВАЕМ ЗАТЕМ НЕСКОЛЬКО СЛОВ О HASKELL ОПРЕДЕЛЯЕМ ПРИМЕР С URL СОДЕРЖАНИЕ СОДЕРЖАНИЕ СОДЕРЖАНИЕ СОДЕРЖАНИЕ ДИАПАЗОНЫ ДЛЯ ЧЕГО ОН НУЖЕН ЛОВИМ НАОБОРОТ П ФУНКЦИИ ВЫСШЕГО ПОРЯДКА ФУНКЦИЯ ПРИМЕНЕНИЯ ИМПОРТИРУЕМ ПЫТАЕМСЯ НАЧНЁМ С C++ О МОДУЛЕ IO A ОСНОВНОЕ ПРАВИЛО НИЧЕГО, КРОМЕ В ЧИСТОМ МИРЕ КИТ ВТОРОЙ ОБ ИМЕНАХ СОБСТВЕННЫЕ КЛАССЫ ТИПОВ ЧТО ЭТО ТАКОЕ ДЕЙСТВИЯ НАД ЭЛЕМЕНТАМИ МЕНЯЕМ ТИП ДЛЯ ЧЕГО ОН НЕИЗМЕННОСТЬ ДАННЫХ БЕЗ КОНЦА ВВОД И ВЫВОД КЛАСС ТИПОВ КЛАСС ТИПОВ КЛАСС ТИПОВ LIST COMPREHENSION О ЛИЦЕ О МОДУЛЯХ ПРИНАДЛЕЖНОСТЬ УМНЫЕ ДИАПАЗОНЫ НЕУДОБНЫЙ СПОСОБ Λ-ФУНКЦИИ ВЫХОД ИЗ ФУНКЦИИ СОСТАВНЫЕ ТИПЫ РАЗОБЛАЧЕНИЕ СПИСКОВ ТИПЫ — ОДНИМ ВЗГЛЯДОМ ВЫЗЫВАЕМ НЕИЗМЕННОСТЬ СПИСКА О СПИСКАХ СОЗДАЁМ НАСЛЕДУЕМЫЕ ТИПЫ DO: ИМПЕРАТИВНЫЙ МИР ОБЪЯВЛЯЕМ ОБЪЯВЛЯЕМ ПРИМЕР О ПРЕЛЮДИИ ЗАЧЕМ ОНИ НУЖНЫ СТРАЖА! ФУНКЦИЯ ТИП ПОЧЕМУ КОНСТАНТА ПРОСТЕЙШИЕ ДЕЙСТВИЯ ИМПОРТИРУЕМ МОДУЛИ ЧИСТОТА VS НЕЧИСТОТА ФУНКЦИЯ КОМПОЗИЦИИ ORD ПОЛЯ КОРОТКАЯ ПРИНАДЛЕЖНОСТЬ КОНФИГУРИРУЕМ ИЛЛЮСТРАЦИЯ ОДНО ПОЛЕ КОРТЕЖИ ЛОКАЛЬНЫЕ ВЫРАЖЕНИЯ ЛОКАЛЬНЫЕ ВЫРАЖЕНИЯ СОБИРАЕМ ОПРЕДЕЛЕНИЕ ГОТОВИМСЯ К РАБОТЕ МОЖЕТ БЫТЬ ДЕЙСТВИЕ VS БЕЗДЕЙСТВИЕ БЛАГОДАРНОСТИ КИТ ПЕРВЫЙ КОМПОНОВКА СУТЬ КТО РАЗОБЛАЧЕНИЕ ФУНКЦИЙ КОНТЕКСТ ТИПА ТРИ КИТА ТИПИЗАЦИИ НЕ ТОЛЬКО ЗАЧЕМ ЭТО НАМ ЗЕРКАЛЬНАЯ КОМПОНОВКА ФУНКЦИИ С ПОБОЧНЫМИ ЭФФЕКТАМИ MONAD ЗАЧЕМ КАК ЭТО ВЫГЛЯДИТ В КОДЕ УКОРОЧЕННАЯ ЗАПИСЬ ТИПОВ ПОЛЕЙ И ЧТО, ЭТО ВСЁ?? О НУЛЬАРНЫХ КОНСТРУКТОРАХ ДЛЯ КОГО ЧТО ЗА ЗВЕРЬ И И ОБРАБОТКА ИСКЛЮЧЕНИЙ SHOW РЕКУРСИВНЫЕ ФУНКЦИИ ВЫВОД FAIL ЛИРИЧЕСКОЕ ВСТУПЛЕНИЕ ХИТРЫЙ СПИСОК

а чего ты добиваешься-то? HR что-ли?

Да. И у нас недавно открылась вакансия клоуна.

http://www.cs.cmu.edu/~15150/

по-человечески

отличный курс для новичков, ага

отличный курс для новичков, ага

Students will require some basic mathematical background, such as the ability to do a proof by mathematical induction, in order to reason about program correctness. In addition, it will be very useful for a student to have developed abstraction skills and to have familarity with the core mathematical structures of Computer Science, such as sets, relations, graphs, and trees.

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

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

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

ты топиком ошибся, или всерьез считаешь, что «новичок» и «минимум академизма» - это матан и теория алгоритмов?

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

Это, правда, не объясняет почему я основы знаю, но мало что понимаю в реальных программах на хаскеле :).

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

HASKELL vs SCALA
Кто победит?

Победит vs

Говорят «Real world haskell» устарела сильно.

Не сильно, когда я читал (2012), проблемы по совместимости были только с исключениями.

Победит vs

visual studio, конечно!

ГОВНО vs ГОВНО
Кто победит?

Вы правы

К сожалению, чаще всего код на Haskell именно таков: трешевый, компактный, но в итоге понятный только самому автору. Цель моей книги - показать, что можно (и нужно) писать на Haskell красивый и сопровождаемый код.

Поясню

Книга «Изучай Хаскелл во имя добра» действительно хороша. Но моя книга отличается от неё.

Во-первых, добрая половина «книги со слоном» приводит примеры с ghci. А если человек планирует (хотя бы попробовать) использовать Haskell на практике, он не будет пользоваться интерпретатором. Напротив, он будет создавать нормальные проекты, с логичной иерархией исходников, которые в итоге будут компилироваться. Поэтому я привожу пример работы с cabal. Кроме этого, поясняю про Hackage и с чем его есть.

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

В-третьих, «книга со слоном» слишком раздута, потому что в ней много справочной информации. Не вижу смысла включать её в книгу, если можно открыть Prelude (и прочие стандартные модули) и прочесть.

Ну и потом, кто сказал, что книга по Haskell для новичков должна быть одна? :-)

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

собственно, сабжевую книгу и следует называть «учимся писать на хаскеле, как на питоне». но зачем? если хочется писать на питоне - есть питон.

Не совсем так...

Это не кодинг-стайл, это правила форматирования корректного кода. В силу того, что код на Haskell является форматно-зависимым, новичок, оформляя код в привычном для себя стиле, может столкнуться с вот такой ошибкой:

Illegal type signature: `IO () main'

или такой:

The type signature for `write' lacks an accompanying binding

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

Введение в монады я привёл

Вы совершенно правы, Haskell без монад весьма беден. Именно поэтому в будущих изданиях я расширю объяснение монад, включая рассмотрение монадных трансформеров.

Полистал немного. Скорее всего книжка своего читателя найдет, и в качестве ознакомительного материала вполне подойдет.

Ну и лично мне не нравится порядок повествования «Монада -> Функтор», вместо кошерного «Функтор -> Аппликативный Функтор -> Моноид -> Монада».

и смех, и грех

Пусть будет, чо)

Вы совершенно правы

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

для начинающих писать на Haskell разжёвывать кортежи -
это как минимум глупо.

Кортежам посвящено всего четыре страницы, одна из которых посвящена рассмотрению готового способа извлечения элементов. Не такое уж и разжёвывание.

Наилучшим вариантом был бы общий курс
функционального программирования

Общих курсов ФП на русском языке я сходу насчитал штук пять.

плюс сжатая документация по языку.

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

И у нас недавно открылась вакансия клоуна.

почему не используете внутренние резервы?

«введений в монады» в интернетах значительно больше чем нужно, в них и проблема. Создается ощущение, что монады - это такой специальный костыль для чистоты IO и возможности использовать do-нотацию для дслей. Нужен именно подробный мануал, а не введение.

Согласен с вами

Подробный мануал нужен, но вначале нужно вменяемое введение. Лично я, пока понял простую суть монад, перелопатил кучу материалов. А всё оказалось значительно проще, и вот эту простоту я и решил объяснить на пальцах. Конечно, в будущем объяснение будет расширяться.

Я в этом хаскеле ноль, но интересуют монады. Просто, хочу узнать что такое. Открыл сразу про них. И увидел снова стандартное объяснение на пайпах, и в итоге:

Последовательность дает нам твердую уверенность, что до тех пор пока утилита ls не завершит свою работу, мы не перейдем к утилите grep.

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

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

Создается ощущение, кокроче, что монады никто не понимает только потому, что нечего там понимать. Это фейк, треп на пустом месте.

Ну да, приведение типов, костыли.

Ну вот, еще один все понял. Ша теперь, не пали контору, не мешай лохов разводить!

начинаются […] про факториал… Эта книга не такая.

Ну и зачем она тогда такая нужна? ☺

но это же совершенно иной уровень!

Открыл сразу про них

А что открыл?

Вот более-менее первоисточники:

http://www.disi.unige.it/person/MoggiE/ftp/ic91.pdf

http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/baastad.pdf

Или совсем просто:

http://vimeo.com/38223410

То есть — монада это теория (aka интерфейс) (тип-эндофунктор, операции вроде unit и bind, их аксиомы) позволяющая явно аксиоматизировать разные модели вычислений (императивные и т.п. — см. ссылки) в чистом языке типа хаскеля. В другом языке это может быть неявно, как данность — никаких «программируемых ;».

Да что бы он ни открыл, все равно ничего бы не понял, по тону обиженного дебила сразу видно же

«монада в общем» - это просто интерфейс. Ну вот как какой-нибудь IEnumerable или IObservable. Просто у этого интерфейса бедная семантика - то есть когда мы видим, что нечто реализует IObservable, то мы знаем, что на эту штуку можно подписаться и она нам будет выдавать какие-то notifications. У IMonad же такой семантики нет - то есть это просто некая штука, у которой есть пара методов с определенным типом.

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

Создается ощущение, кокроче, что монады никто не понимает только потому, что нечего там понимать.

А, ок, ты и так все понял правильно.

Все эти объяснения не говорят о том, как мондады связаны с программированием.

В другом языке это может быть неявно, как данность — никаких «программируемых ;».

Во-первых ; - это не мондада, а аппликативный функтор. Во-вторых, никаких «программируемых ;» и в хачкиле нету. Ну и монады есть в любом языке (да, именно в явном виде), не только в хаскеле. И тот факт, что их никто там не использует как бы намекает, не правда ли?

Во-первых ; - это не мондада

Это я Вадлера цитирую (http://vimeo.com/38223410). Монада, если понимать, что ; в том числе протаскивает контекст созданный слева в выражение справа, то есть T x = con(...) ; use(x) как con(...) >>= \(x :: T) -> use(x) или просто con(...) >>= use.

Во-вторых, никаких «программируемых ;» и в хачкиле нету.

Там do-нотация — do { x; y <- z; ...; } раскрывается в (>>=) которые именно что «программируются» — пишем какие угодно типы, делаем себе какие угодно instance Monad, используем do-нотацию с семантикой которую мы сами задали, ; ведёт себя как нам нужно. То же касается RecursiveDo, mdo, monad comprehensions, rebindable do (http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html).

Ну и монады есть в любом языке (да, именно в явном виде), не только в хаскеле.

Как возможность написать свои функции return/bind — да. Как do-нотация или for-comprehension из Haskell/Scala — нет. Ну и я скорее именно про IO monad — в хаскеле её можно сбоку приделать, а вот в другом языке (C++, допустим) уже нельзя отделить эффекты от чистого кода явно и с гарантиями.

И тот факт, что их никто там не использует как бы намекает, не правда ли?

Их нельзя не использовать, так как дофига типов и так монады (seq-like, pointer/option, cont, function, tuple, future, async, state, parser, etc).

https://www.google.com/search?q=flatMap site:www.scala-lang.org/api

у вас там (вы же автор?) шрифты просто ужасны. Это (pdf-ку) невозможно читать.

Монада, если понимать, что ; в том числе протаскивает контекст созданный слева в выражение справа, то есть T x = con(...) ; use(x) как con(...) >>= \(x :: T) -> use(x) или просто con(...) >>= use.

Он ничего не протаскивает. ; - это аппликативный функтор. монады для описания ; не нужны. Сказать что "; - монада" примерно то же самое, как сказать, что нам надо уметь извлекать корень, чтобы сложить 2 и 2. Ведь, действительно, 2+2 = sqrt((2+2)^2)! Без извлечения корня это выражение никак не вычислить.

Там do-нотация — do { x; y <- z; ...; } раскрывается в (>>=) которые именно что «программируются»

То есть это просто синтаксический сахарок, который подставляет >>= вместо ;. Давай уж будет говорить о языковых возможностях с точностью до синтаксического сахара? А то иначе смысла никакого нет - важна ведь семантика.

Как do-нотация или for-comprehension из Haskell/Scala — нет.

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

Их нельзя не использовать

Как это нельзя? Конечно можно! И практически нигде их и не используют.

так как дофига типов и так монады

Ну это банальный обман. Если у нас есть нечто, для чего можно определить bind/return с нужными типами удовлетворяющее монадическими законами - оно монадой не становится. монадой оно станет только тогда, когда мы семантически будем воспринимать это монадой. Ну так же как нечто становится IObservable не тогда, когда мы реализуем метод subscribe с нужным типом, а тогда, когда мы начинаем воспринимать это нечто как штуку, которая может рассылать сообщения своим подписчикам. При этом subscribe может быть еще не реализован. Так что чтобы сказать, что нечто является монадой - надо сперва понять, что такое монада, какова семантика этог оинтерфейса? но семантики у него нет (т.к. интерфейс слишком беден, его нельзя ни для чего использовать), по-это просто монад как таковых не существуют. Существуют лишь группы монад или конкретные монадически инстансы (которые не являются монадами сами по себе, понятное дело, раз монад не существует, но могут являться конкретной монадической группой).

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

Just for fun такое никто никогда читать не будет.

Just for fun такое никто никогда читать не будет.

Действительно, лучше пойти пиво с «поцонами на раёне» попить.

; - это аппликативный функтор

«Функтор», «точечный функтор», «аппликативный функтор» или «монада» это всё по отношению к типу * -> * говорят, то есть эндофунктору на категории типов. Можно сказать «List это аппликативный функтор» или «List это монада», но никак не "; - это аппликативный функтор".

; это функция, если уж на то пошло. Ты хотел сказать, что это (*>) :: f a -> f b -> f b (из Control.Applicative, для некоторого аппликативного функтора f :: * -> *)? Ещё раз:

T x = con(...) ; use(x)

con(...) >>= \(x :: T) -> use(x)

То есть (>>=), не (*>).

То есть это просто синтаксический сахарок, который подставляет >>= вместо ;

Да, что характерно — ; заменим (>>=), то есть монадической операцией, а не аппликативной (иначе бы в хаскелях и скалах скакали вокруг аппликативных функторов, а не монад).

Давай уж будет говорить о языковых возможностях с точностью до синтаксического сахара?

Не, ну речь была про ; — сахар для (>>=), ок. Что Вадлер сказал — примерно «как нам в чистом языке запилить императивщину? С помощью монад, то есть (>>=), то есть программируемого ;», так же оказывается, что сам этот интерфейс более общий и подходит для самых разных типов.

Конечно, можно - если есть макросы

Мандады на макаросах и борщесиле, ага.

Если у нас есть нечто, для чего можно определить bind/return с нужными типами удовлетворяющее монадическими законами - оно монадой не становится

Становится, по определению. Вот, например, List, Option или Future — монады.

Вообще http://www.scala-lang.org/api/current/index.html#scala.collection.TraversableOnce$$MonadOps@inheritance-diagram — implicitly 328 classes/traits.

Ну и монады есть в любом языке (да, именно в явном виде), не только в хаскеле.

Покажи мне монады в Java, пожалуйста.

Общих курсов ФП на русском языке я сходу насчитал штук пять.

Этого достаточно, чтобы не разжёвывать то же самое для самых маленьких ещё раз, разве нет?

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

Подобное можно сказать о сторонних библиотеках, но никак не о base, которая описана подробнее просто некуда. Мне для изучения языка хватило Haskell wiki и пары небольших проектов типа xmonad в качестве наглядных примеров.

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