Haskell *

Свойства и законы. Сценарии. Inversion of Control в Haskell.

Совсем немного теории

В прошлой части мы убедились, что очень легко запутаться в плохо спроектированном коде. К счастью, с древних времен нам известен принцип “разделяй и властвуй”, — он широко применяется при построении архитектуры и дизайна больших систем. Мы знаем разные воплощения этого принципа, как-то: разделение на компоненты, уменьшение зависимости между модулями, интерфейсы взаимодействия, абстрагирование от деталей, выделение специфических языков. Это хорошо работает для императивных языков, и надо полагать, что будет работать в функциональных, за тем исключением, что средства реализации будут другими. Какими же?

Восходящее проектирование в ФП. Идея — основа хорошего дизайна. Антипаттерны в Haskell.

Немного теории

В прошлой части мы построили высокоуровневую архитектуру приложения. Мы определили подсистемы и их связи, а также разделили программу на три слоя: Application, Game Logic, Views. По логике, следующий этап — дизайн приложения. По важности этот этап не уступает предыдущему, так как именно в ходе дизайна мы должны поддержать все функциональные требования, определить фактическую структуру подсистем, описать основные технические проблемы, применить какие-либо типовые решения или придумать другие. Но прежде попробуем ответить на вопрос: каков он, хороший дизайн ПО? По каким критериям мы определяем «хорошесть» дизайна?

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

Это статья попытка показать, что сила функциональных языков и в первую очередь Хаскеля — это в том числе и силе функторов и монад.

Введение

В мире функционального программирования есть один большой пробел, а именно почти не освещена тема высокоуровневого дизайна больших приложений. Я решил для себя изучить этот вопрос. Есть ли существенные отличия дизайна приложений в ФП-мире от оного в мире императивном? Что такое «каноничный ФП-код»? Какие существуют идиомы разработки, есть ли смысл вообще говорить о паттернах проектирования в применении к ФП? Эти и другие важные вопросы часто вспыхивают то там, то здесь, но покамест мне не известно ни одной книги, аналогичной книге Банды Четырех. Вероятно, мои изыскания уже кто-то повторил, однако тем лучше: схожие результаты подтвердят правильность, иные — укажут на место в теории, которое необходимо доработать.

Добрый день!
Мы в издательстве «Питер» подумали, что в России не хватает книг по Haskell и решили обратиться к сообществу с вопросом, стоит ли делать перевод одной из таких книг и, если да, — то какой именно?

На наш взгляд, на рынке присутствует только одна достойная книга — русский перевод Learn You a Haskell for Great Good (в русском названии «Изучай Haskell во имя добра!»)

Из кандидатов на русское издание мы рассматриваем следующие книги:

Переводчик из меня совершенно никакой, но я просто не мог пройти мимо этой статьи, ибо она излучает волны крутости, а концентрация дзена в ней зашкаливает. Поэтому welcome.

Введение

Недавно я обнаружил интересную игру под названием VimGolf. Цель этой игры заключается в том, чтобы преобразовать кусок текста из одной формы в другую наименьшим возможным количеством нажатий клавиш. Пока я играл на этом сайте с разными пазлами, мне стало любопытно — а какие привычки редактирования текста есть у меня? Мне захотелось лучше понять способы манипулирования текстом в Vim и проверить, смогу ли я найти неэффективные моменты в моем рабочем процессе. Я провожу огромное количество времени в моем текстовом редакторе, поэтому устранение даже незначительных шероховатостей может привести к значительному увеличению производительности. В этом посте я расскажу о своем анализе и о том, как я уменьшил количество нажатий клавиш при использовании Vim. Я назвал эту игру Vim-крокет.

В этой статье мы попытаемся рассмотреть всё разнообразие Алгебраических Типов Данных.

Надо сказать, задача это достаточно неподъёмная, и понять человеку, если он ранее с Алгебраическими Типами не имел дело — не очень просто.
АТД были впервые использованы в языке Hope, но основную популярность они приобрели благодаря языкам ML, такими как Standart ML, OCaml, F#, и языку Haskell.
Ныне АТД в той или иной мере поддерживаются в значительно большем количестве языков: Scala, Rust, Nemerle, Racket,…
АТД — это универсальный тип данных. С помощью него можно представить большинство типов данных.
АТД называются алгебраическими, потому что их можно представить как некую алгебраическую композицию типов его составляющих. Это знание даёт своё преимущество: понимая свойства алгебраической композиции, можно посчитать какой тип необходим для построения тех или иных данных.
Будем рассматривать типы на основе языка Haskell, однако подобного с лёгкими изменениями можно добиться в других языках с поддержкой АТД.

Too late — 'cause I got it now
there are monads all around
IO, State and lists abound
It's easy, like those people say
but my program got abstracted all away!
Maybe — o o o,
It's a monad too, I know
Why should I use another language at all?

Снова безумный адепт Haskell, и еще одна попытка доказать его практичность. Нестареющая классика.
Я постараюсь рассказать шикарную историю (не ведитесь на пафосную рекламу), в которой будут все необходимые компоненты блокбастера (я серьезно, не ведитесь) — знакомые герои, хорошо продуманная вселенная и открытая концовка (ну что ж...).

Уже было описано как реализовать монады на C++ без классов типов. Я же хочу показать, как можно реализовать классы типов, использую в качестве примера монады.
Этот прием широко применяется в языке Scala, но может быть использован и в C++. Кратко я его описал в качестве иллюстрации трудностей унифицированного описания библиотек, сейчас же продемонстрирую его реализацию.
Нужно отметить что классы типов применяются не только в декларативных языках, как Haskell и Mercurry, но о нашли свое отражение в достаточно классических Go и Rust.
Этот прием так же подходит для реализации мультиметодов из Common Lisp и Clojure.

C++ я не брал в руки уже лет шесть, так что код может быть не идеоматичным и не использовать новые (полезные) фичи.
Кроме того, я полностью игнорирую проблему управления памятью — практикующие C++ справятся с этим лучше меня.
Работоспособность кода проверялась на gcc 4.7.3.

Привет Habr! Сегодня мы поговорим о полиморфизме функций, операторах и карринге. Напоминаю, что лекции рассчитаны на новичков, а конспект предпологает сжатую форму изложения. Если все еще интересно…

Привет Habr! Сегодня я достал свои старые конспекты по курсу «Haskell как первый язык программирования» Сергея Михайловича Абрамова и попробую максимально доходчиво и с примерами рассказать об этом замечательном языке тем, кто с ним еще не знаком. Рассказ ориентирован на неподготовленного читателя. Так что, даже если вы впервые услышали слово Haskell…

Это достаточно вольный перевод статьи. Дело в том, что несмотря на конструкции в одну строчку, материал сложен для понимания.
Беря во внимание то, что в комментариях Прелюдия или как полюбить Haskell просили, чтобы код был понятный, я внёс достаточно ремарок, и, надеюсь, код будет понятен и тем, кто далёк от Хаскеля.

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

Странные петли — это запутанные категории, когда двигаясь вверх или вниз в иерархической системе, находишь то же самое, откуда начал движение.
Зачастую такие петли содержат само-референтные ссылки.
Например, подобной странной петлёй обладает рекурсивные акронимы: «PHP — PHP: Hypertext Preprocessor».
Ну, и на сегодняшний день наиболее загадочным словом, содержащим странные петли, является понятие «я».

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

Немецкий математик Лёб мигрировал в 39-м году ХХ-го столетия в Великобританию. Лёб, в частности, развивал математическую логику и миру прежде всего известен Теоремой Лёба. Это теорема развивала труды Гёделя о неполноте математики. Теорема Лёба о взаимосвязи между доказуемостью утверждения и самим утверждением, она гласит, что

во всякой теории, включающей аксиоматику Пеано (аксиоматика о натуральных числах), для любого высказывания P доказуемость высказывания «если доказуемо P, тогда P истинно» возможна только в случае доказуемости самого высказывания P.

Всю эту сложность высказывания можно записать символически:


Можно ли такую функцию написать на Хаскеле?! Можно! И всего в одну строчку!

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

Известно, что задача определения того, истинна ли некоторая функция Integer -> Bool хотя бы для одного числа вычислительно неразрешима. Однако, нечто, на первый взгляд кажущееся как раз таким оракулом (а именно, функцией (Integer -> Bool) -> Maybe Integer) будет описано в этой статье.

Для начала, зададим свой тип натуральных чисел, практически дословно следуя их обычному математическому определению (почему это нужно будет видно в дальнейшем):

data Nat = Zero | Succ Nat deriving (Eq, Ord, Show)

Другими словами, натуральное число — это либо ноль, либо некоторое натуральное число, увеличенное на единицу (Succ от слова successor).

Также, для удобства, определим основные операции (сложение, умножение, конвертация из Integer) над числами в таком представлении:

instance Num Nat where
    Zero + y = y
    Succ x + y = Succ (x + y)

    Zero * y = Zero
    Succ x * y = y + (x * y)

    fromInteger 0 = Zero
    fromInteger n = Succ (fromInteger (n-1))

Хаскель отличает себя от большинства функциональных языков тем, что имеет глубокие культурные корни из области математики и информатики, которые дают обманчивое впечатление, что Хаскель плохо подходит для решения практических задач. Однако, чем больше вы знаете Хаскель, тем больше вы цените то, что теория часто является наиболее практическим решением многих общих проблем программирования. Этой статьёй хочется подчеркнуть эту точку зрения тем, что мы смешаем имеющиеся в наличии теоретические основы и создадим чистую пользовательскую систему потоков.

Я давно обещался написать статью о том, как себя показал Haskell в реальных задачах в продакте.

Для тех, кто не уследил — его в начале 2012 пролоббировали и с энтузиазмом начали внедрять программисты в Селектеле. Тогда же я обещал опубликовать отчёт о том, насколько «это всё» можно использовать.

Продакт в коммерческом проекте — это не в маленькая песочница «для себя», не академический эксперимент в области Computer Science. Это бесконечная борьба за «линию партии», когда вокруг ад, ужас и погибель, а оно всё равно должно работать. Int64 в XML-RPC кодируется строкой (потому что int'ы в XML-RPC signed int32), openssl при чтении нескольких сертификатов из файла читает только первый из них, в bool надо писать либо «1», либо «0», но иногда — «2», ибо только так придумали закодировать третий режим — и т.д. и т.п. В этих условиях требования к языку постепенно перерастают в требования к его экосистеме, инфраструктуре, готовности адаптироваться к реальному миру.

Я буду писать о Haskell с позиций product owner'а, менджера проекта, системного администратора, но никак не программиста. Так что не ожидайте от меня задушевных восторгов о том, как изящно через монадки можно сделать семигрупоид и как здорово выводить типы через типы с помощью типов.

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

Начнём с потребительских свойств.

Когда я работал над своей магистерской диссертацией, я пообещал себе, что опубликую ее в Интернете под свободной лицензией. Я получил степень, но, к сожалению, натолкнулся на одно из неписаных правил ВУЗов — когда вы тратите на интересующий вопрос много времени, он вам надоедает.
Наконец, спустя год, я все-таки ее публикую.
Для тех, кому лень знакомиться с моим полным трудом (в любом случае, 60 страниц текста это не так много для исследовательской работы, но это все же не мало), я предлагаю краткую версию статьи. Прошу заметить, что краткая версия не учитывает некоторые важные сведения, поэтому я прошу писать отзывы только о полной версии.

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

Суть их рассуждений в следующем:

1. Статической типизации недостаточно для выявления багов, поэтому необходимы модульные тесты;
2. Статическая типизация становится лишней, так как у вас есть тесты;
3. Из-за статической типизации некоторые корректные программы могут выдавать предупреждения на стадии компиляции.

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

Да-да, все правильно — теперь под iOS можно писать на Haskell! Вот сообщение одного из создателей этого чуда (оригинал):

Привет всем!
Мы со Stephen Blackheath безумно рады сообщить, что на данный момент в GHC появилась возможность компилировать в нативный код, поддерживаемый iOS устройствами, а также iOS симулятором. Все, что нужно, вы найдете здесь: ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS
Если коротко, то вы можете использовать «ghc-ios myFiles.hs» для получения универсальных ARMv7/ARMv7s/i386 библиотек и подключать их к проекту в Xcode.
Сейчас Стивен работает над чудесными FRP-powered играми, я тружусь над проектом SpaceTime, который скоро анонсирую, а вы все просто обязаны бежать к компьютеру и начинать писать под iOS на лучшем в мире языке:)

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

Линзы

Ваш билет к элегантному коду — это библиотека линз (lens).

Предисловие

Когда я начал изучать Хаскель, я был почти сразу поражён. Для начала, нырнув с головой в актуальные рабочие проекты, открыл, что большинство настоящих библиотек используют языковые расширения, присутствующие только в GHC (Glasgow Haskell Compiler). Это меня покоробило слегка, прежде всего потому, кто захочет использовать язык настолько немощный, что будет необходимо использовать расширения, присутствующие лишь у одного поставщика. Ведь так?
Хорошо, я решился снова это осилить и узнать всё об этих расширениях, и я вывел три горячих топика для общества Хаскеля, которые решали похожие проблемы: Обобщённые Алгебраические Типы Данных, Семьи Типов и Функциональные Зависимости. Пытаясь найти ресурсы, которые обучают о них, я смог найти только статьи, описывающие, что это такое, и как их использовать. Но никто, на самом деле, не объяснял зачем они нужны!.. Поэтому я решил написать эту статью, используя дружественный пример, пытаясь объяснить зачем всё-таки нужны Семьи Типов.



Вы когда-нибудь слышали про Покемонов? Это замечательные существа, которые населяют Мир Покемонов. Вы можете считать, что они как животные с экстраординарными способностями. Все покемоны владеют стихией, и все их возможности зависят от этой стихии. Например, покемон Огненной стихии может дышать огнём, в то время как покемон Водной стихии может брызгать струями воды.
Покемоны принадлежат людям, и их специальные способности могут быть использованы во благо для продуктивной деятельности, но некоторые люди всего лишь используют своих покемонов для борьбы с другими покемонами других людей. Эти люди называют себя Тренерами Покемонов. Это может сначала звучать как жестокое обращение с животными, но это очень даже весело и все, похоже, рады, включая покемонов. Имейте в виду, что в мире покемонов, кажется, всё в порядке, даже если 10-летние покидают дом, дабы рисковать своими жизнями ради того, чтобы стать самыми лучшими Тренерами Покемонов, как будто никто и никогда таковыми не становился.

Мы собираемся использовать Хаскель для того, что бы представить ограниченную (и даже несколько упрощённую, да простят меня фанаты) часть мира покемонов.