Среда разработки

Прикладное введение в монадные трансформеры, от проблемы к решению

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

Всё как обычно: несколько лаконичных однострочных выражений (да, детка, это Scala!), несколько странных ошибок компилятора (о, нет, Scala, нет!), лёгкое сожаление о том, что вы написали такой запутанный код… И вдруг вы сталкиваетесь со странной проблемой: выражение for не компилируется. «Ничего страшного», — думаете вы: «сейчас гляну на StackOverflow», как вы это делаете ежедневно. Как все мы это делаем ежедневно.

Но сегодня, похоже, неудачный день.

За последнее время мы очень многое узнали о монадах. Мы уже разобрались что это такое и даже знаем как их можно нарисовать, видели доклады, объясняющие их предназначение. Вот и я решил заскочить в уходящий монадный поезд и написать по этой теме, пока это окончательно не стало мейнстримом. Но я зайду с немного другой стороны: здесь не будет выкладок из теории категорий, не будет вставок на самом-лучшем-языке, и даже не будет scalaz/shapeless и библиотеки parser-combinators. Как известно, лучший способ разобраться как что-то устроено — сделать это самому. Сегодня мы с вами будем писать свою монаду.

Задача

Возьмем для примера банальную задачу: парсинг CSV-файла. Допустим нам требуется распарсить строки файла в case classes, чтобы потом отправить их в базу, сериализовать в json/protobuf и так далее. Забудем про escaping и кавычки, для еще большей простоты, считаем что символ разделителя в полях встречаться не может. Думаю, если кто-то решит затащить это решение в свой проект, докрутить эту фичу будет не трудно.

В стандартной библиотеке Scala методы коллекций (map, flatMap, scan и другие) принимают экземпляр типа CanBuildFrom в качестве неявного параметра. В этой статье мы подробно разберём, для чего нужен этот трейт, как он работает и чем может быть полезен разработчику.

Неразмеченные Конечные Интепретаторы (Tagless Final interpreters — прим. пер.) — это альтернативный подход традиционным Алгебраическим Типам Данных (и обобщённым ADT), основанный на реализации паттерна "интерпретатор". Этот текст представляет "неразмеченный конечный" подход в Scala, и демонстрирует каким образом Dotty с его недавно добавленными типами неявных функций делает этот подход ещё более привлекательным. Все примеры кода — это прямое переложение их Haskell версий, представленных в Typed Tagless Final Interpreters: Lecture Notes (раздел 2).

Паттерн "интерпретатор" в последнее время привлекает всё больше внимания в сообществе Scala. Множество усилий было затрачено на борьбу с наиболее ярким недостатком решений, основанных на ADT/GADT: расширяемость. Для начала можно взглянуть на typeclass Inject из cats как на реализацию идей Data Type à la Carte. Библиотека Freek предоставляет средства для комбинирования более двух алгебр, используя украшения с задействованием аппарата операций на уровне типов. Решение, предложенное в работе Freer Monads, More Extensible Effects также ставит акцент на расширяемости, и вдохновлено набором небольших Scala-библиотек, таких как eff, emm и paperdoll. Неразмеченные конечные интерпретаторы подходят в некотором смысле с противоположной стороны, используя типы классов в своём непосредственном основании вместо более традиционных ADT/GADT. Они также поставляются с большим превосходством в расширяемости "из коробки" без каких-то явных опасностей.

Время от времени у меня возникает желание придумать свой собственный маленький язык программирования и написать интерпретатор. В этот раз я начал писать на scala, узнал про библиотеку parser combinators, и был поражён: оказывается, можно писать парсеры легко и просто. Чтобы не превращать статью в пособие по "рисованию совы", ниже приведёна реализация разбора и вычисления выражений типа "1 + 2 * sin(pi / 2)".

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

Для сравнения:

• длинный пример на java
• короткий, но непонятный пример на C#
• пример на java с использованием parboiled

Итак, если вам не терпится увидеть результат:

object FormulaParser extends RegexParsers with PackratParsers {

    def id: Parser[Id] = "[a-zA-Z][a-zA-Z0-9_]*".r ^^ Id

    def number: Parser[Number] = "-" ~> number ^^ (n => Number(-n.value)) |
        ("[0-9]+\\.[0-9]*".r | "[0-9]+".r) ^^ (s => Number(s.toDouble))

    def funcCall: Parser[FuncCall] = id ~ ("(" ~> expression <~ ")") ^^ {case id ~ exp => FuncCall(id, exp)}

    def value: Parser[Expression] = number | funcCall | id | ("(" ~> expression <~ ")")

    lazy val term: PackratParser[Expression] = term ~ ("*" | "/") ~ value ^^ binOperation | value

    lazy val expression: PackratParser[Expression] = expression ~ ("+" | "-") ~ term ^^ binOperation | term
    ...
}

Посмотрите на следущую строчку:

def value: Parser[Expression] = number | funcCall | id | ("(" ~> expression <~ ")")

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

Это возможно по следующим причинам:

1. В scala разрешено давать методам замечательные названия типа "~", "~>", "<~", "|", "^^". Комбинация парсеров p и q записывается как p~q, а возможность выбрать один из них: p|q. Читается намного лучше, чем p.andThen(q) или p.or(q)
2. Благодаря неявным преобразованиям (implicits) и строчка "abc" и регулярное выражение "[0-9]+".r при необходимости превращаются в парсеры.
3. В языке мощная статическая система типов, которая позволяет ловить ошибки сразу.

Думаю, мне удалось Вас заинтересовать, поэтому дальше всё будет по порядку.

Перевод статьи Pedro Palma Ramos "Building Web applications with Scala.js and React — Part 1"

Мне, как Scala-программисту, разрабатывающему веб-приложения, обычно неприятен переход от аккуратного, функционального и типобезопасного Scala бэкенда к фронтенду, написанному на JavaScript. К счастью, существует мощная и зрелая альтернатива нашему (не всегда) любимому стандартному языку для Web.

Scala.js — это реализация Scala за авторством Sébastien Doeraene, которая компилирует код Scala в JavaScript, а не в байт-код JVM. Она поддерживает полную двустороннюю функциональную совместимость между Scala и JavaScript-кодом и, следовательно, позволяет разрабатывать фронтенд веб-приложения на Scala с использованием библиотек и фреймворков JavaScript. Она также способствует уменьшению дублирования кода по сравнению с обычным веб-приложением на Scala, поскольку позволяет повторно использовать на фронтэнде модели и бизнес-логику, разработанные для серверной части.

React, с другой стороны, представляет собой веб-фреймворк для создания пользовательских интерфейсов в JavaScript, разработанный и поддерживаемый Facebook и другими компаниями. Он способствует чистому разделению между обновлением состояния приложения в ответ на пользовательские события и визуализацией представлений на основе указанного состояния. Поэтому фреймворк React особенно подходит для функциональной парадигмы, которая используется при программировании на Scala.

Часть 1. Функциональная

Эта статья (если быть до конца честным — набор заметок) посвящена ошибкам, которые совершают новички, ступая на путь Scala: не только джуниоры, но и умудренные опытом программисты с сединами в бороде. Многие из них до этого всегда работали лишь с императивными языками такими как C, C++ или Java, поэтому идиомы Scala оказываются для них непонятными и, более того, неочевидными. Поэтому я взял на себя смелость предостеречь новообращённых и рассказать им об их типичных ошибках — как совсем невинных, так и тех, что в мире Scala караются смертью.

Часть 3. Свойства

В предыдущих частях мы уже успели познакомиться со свойствами и опробовать их в связке с генераторами. В этом туториале мы рассмотрим свойства подробнее. Статья состоит из двух частей: первая — техническая, в ней будет рассказано про комбинаторы свойств, а также другие возможности библиотеки ScalaCheck. Эта часть будет посвящена различным техникам тестирования.

Вводная

Часть 2. Генераторы

В вводной статье серии вы, надеюсь уже, успели познакомиться с генераторами. В этом туториале мы закрепим полученные знания, научимся писать собственные (в том числе рекурсивные) генераторы. Хотя он и посвящен генераторам, про свойства мы тоже не забудем. Более того, мы будем их активно использовать, демонстрируя всю мощь механизма генераторов. Рассмотрим механизм предусловий (preconditions). Возможно, более логичным было бы посвятить свойствам вторую статью серии и, возможно, это стало бы правильным решением. Однако, по моим личным наблюдениям, наибольшие трудности вызывают именно генераторы. Свойства мы рассмотрим в следующей статье.

Про ScalaCheck

Часть 1. Введение.

ScalaCheck — это комбинáторная библиотека, значительно облегчающая написание модульных тестов на Scala. В ней используется подход property-based тестирования, впервые реализованный в библиотеке QuickCheck для языка Haskell. Существует множество реализаций QuickCheck: как для Java, C, а так же других языков и платформ. Использование данного подхода позволяет значительно сократить время на разработку тестов.

Эта серия статей во многом похожа на мою предыдущую, посвященную Parboiled, поэтому и структура повествования будет похожей. Я расскажу вам, для чего всё это нужно, затем мы научимся смотреть на мир сквозь призму свойств и генераторов, а потом перейдём к более сложным вещам. Заинтересовало? Прошу под кат.

При слове "полиморфизм" сразу вспоминается объектно-ориентированное программирование, в котором полиморфизм является одним из столпов (Полиморфизм для начинающих). (Причём, по-видимому, более важным, чем другие столпы.) Оказывается, что можно достичь сходного эффекта и другим путём, который в ряде случаев оказывается более предпочтительным. Например, с помощью классов типов можно приписать новые возможности уже существующим типам, у которых нельзя изменить предка, или, используя тип данных с несовместимыми классами, "решить" проблему множественного наследования.