Информационный портал по безопасности

DSL (Domain-specific language) — язык, специализированный для конкретной области применения (Википедия)

На написание этого поста меня натолкнула статья "Почему Kotlin отстой", в которой автор сетует на то, что в Kotlin "нет синтаксиса для описания структур". За некоторое время программирования на Kotlin у меня сложилось впечатление, что в нём если нельзя, но очень хочется, то можно. И я решил попробовать написать свой DSL для описания структуры данных. Вот что из этого получилось.

В нашем блоге на Хабре мы пишем не только о темах, связанных с информационной безопасностью, но уделяем значительное внимание вопросам разработки софта — например, ведем цикл о создании и внедрении инструментов DevOps. Сегодня же речь пойдет об использовании предметно-ориентированных языков (Domain-specific language, DSL) для решения конкретных задач с помощью Python.

Материал подготовлен на основе выступления разработчика Positive Technologies Ивана Цыганова на конференции PYCON Russia (слайды, видео).

29 сентября в Москве прошла мини-конференция JetBrains Night: 7 часов разработчики из JetBrains рассказывали разработчикам из других компаний о том, что компания делает, зачем, и что будет делать дальше, а потом отвечали на вопросы, обсуждали общие проблемы и вообще делились опытом (т.е. слушали, как разработчики из других компаний рассказывают им о том, что они делают и почему им удобно или пока еще не очень удобно делать это с помощью того, что делает JetBrains).

На Хабре мы постепенно публикуем видео всех докладов, чтобы можно было в комментариях обсудить то, что не успели обсудить на JetBrains Night, особенно с теми, кто не смог приехать лично.

В предыдущих постах Дмитрий Жемеров рассказывал про язык Kotlin (там до сих пор продолжается умеренно живая дискуссия в комментариях), а затем Максим Мазин и Валерия Андрианова делились практическими советами по интеграции серверных продуктов и использовании новых Agile-досок.

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

Всем привет!

Эта статья про реализацию одного конкретного DSL (domain specific language, предметно-ориентированный язык) для регулярных выражений средствами Kotlin, но при этом она вполне может дать общее представление, о том, как написать свой DSL на Kotlin и что обычно будет делать "под капотом" любой другой DSL, использующий те же возможности языка.

Многие уже используют Kotlin или хотя бы пробовали это делать, да и остальные вполне могли слышать о том, что Kotlin располагает к написанию изящных DSL, чему есть блестящие примеры — Anko и kotlinx.html.

Конечно же, для регулярных выражений подобное уже делали (и ещё: на Java, на Scala, на C# — реализаций много, похоже, это распространённое развлечение). Но если хочется попрактиковаться или попробовать DSL-ориентированные языковые возможности Kotlin, то добро пожаловать под кат.

Процесс сигнатурного анализа кода в нашем проекте PT Application Inspector разбит на следующие этапы:

парсинг в зависимое от языка представление (abstract syntax tree, AST);

преобразование AST в независимый от языка унифицированный формат;

непосредственное сопоставление с шаблонами, описанными на DSL.

О первых двух этапах было рассказано в предыдущих статьях "Теория и практика парсинга исходников с помощью ANTLR и Roslyn" и "Обработка древовидных структур и унифицированное AST". Данная статья посвящена третьему этапу, а именно: различным способам описания шаблонов, разработке специализированного языка (DSL) для их описания, а также примерам шаблонов на этом языке.

Содержание

• Способы описания шаблонов
  
  
  
  • Hardcoded
  
  
  • JSON, XML или другой язык разметки
  
  


• Собственный язык описания шаблонов
  
  
  
  • Целесообразность
  
  
  • Синтаксис
  
  
  • Примеры шаблонов
    
    
    
    • Жестко заданный пароль (все языки)
    
    
    • Слабый генератор случайных чисел (C#, Java)
    
    
    • Утечка отладочной информации (PHP)
    
    
    • Небезопасное SSL соединение (Java)
    
    
    • Пароль в комментарии (все языки)
    
    
    • SQL-инъекция (C#, Java, PHP)
    
    
    • Куки без атрибута безопасности (PHP)
    
    
    • Пустой блок обработки исключения (все языки)
    
    
    • Небезопасный куки (Java)
    
    
    • Перехват незакрытого курсора (PL/SQL, T-SQL)
    
    
    • Чрезмерно расширенные полномочия (PL/SQL, T-SQL)
    
    
  
  


• Заключение

Это 5-я статья цикла по разработке, управляемой моделями. В предыдущих статьях мы уже разобрались с метамоделями, валидацией моделей, некоторыми нотациями для моделей (диаграммы и таблицы). Всё это было в рамках пространства моделирования MOF. Сегодня мы построим мост в пространство моделирования EBNF – познакомимся с текстовой нотацией для MOF-моделей.

Часть 4. Суровая действительность

Как заставить Parboiled работать еще быстрее? Каких ошибок лучше не допускать? Что делать с наследством в виде Parboiled1? На эти, а так же другие вопросы призвана ответить заключающая статья серии.

Структура цикла:

• Часть 1. Почему Parboiled?


• Часть 2. Сопоставление текста


• Часть 3. Извлечение данных


• Часть 4. Суровая действительность

Часть 1. Почему Parboiled?

Сегодня, в свете бурного роста популярности функциональных языков программирования, всё чаще находят себе применение комбинаторы парсеров — инструменты, облегчающие разбор текста простым смертным. Такие библиотеки, как Parsec (Haskell) и Planck (OCaml) уже успели хорошо себя зарекомендовать в своих экосистемах. Их удобство и возможности в своё время подтолкнули создателя языка Scala, Мартина Одерски, внести в стандартную библиотеку их аналог — Scala Parser Combinators (ныне вынесены в scala-modules), а знание и умение пользоваться подобными инструментами — отнести к обязательным требованиям к Scala-разработчикам уровня A3.

Эта серия статей посвящена библиотеке Parboiled — мощной альтернативе и возможной замене для Scala Parser Combinators. В ней мы подробно рассмотрим работу с текущей версией библиотеки — Parboiled2, а также уделим внимание Parboiled1, так как большая часть существующего кода всё ещё использует именно её.

Структура цикла:

• Часть 1. Почему Parboiled?


• Часть 2. Сопоставление текста


• Часть 3. Извлечение данных


• Часть 4. Суровая действительность

Чуть правее наклон — упадет, пропадет!
Чуть левее наклон — все равно не спасти!
Но спокойно, ему остается пройти
Всего две четверти пути!

Владимир Высоцкий "Натянутый канат"

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


Даже без дамок! Фигуры двигаются вперёд и могут «бить» противника, по привычным нам правилам "Шашек" (перепрыгивая через фигуру). Дойдя до последней линии доски, они ни во что не превращаются, но могут брать фигуры противника, поскольку взятия «назад» разрешены. В этом отношении, разрабатываемая игра похожа на «Осетинские шашки», описанные в одной из предыдущих статей. Взятие обязательно и, из всех возможных ходов, игрок должен выбрать ход, берущий максимальное количество фигур. Игра завершается, когда один из игроков не может выполнить очередной ход (заперт или потерял все фигуры).

Разумеется, речь идёт не о том, чтобы «закодить очередные шашки» (это можно было бы сделать и с меньшими усилиями). Я хочу разработать «метаигровую» систему, позволяющую описывать достаточно сложные логические игры, используя простой DSL и, в идеале, не обладая продвинутыми навыками программирования (то есть, ровно то, что делает Zillions of Games, но в полностью открытом и кроссплатформенном проекте).

Скорее всего, из разработчиков, пользующихся Java, и в особенности Android-разработчиков многие уже знают про Kotlin. Если нет, то никогда не поздно узнать. Особенно если Java не устраивает вас чем-то как язык — что наверняка так — или если вы владеете Scala, но и этот язык вам не подходит, что тоже не исключено.

Если кратко, то Kotlin — это статически типизированный язык, ориентирующийся на JVM, Android (компилируется в байт-код Java) и веб (компилируется в javascript). JetBrains, разработчик языка, ставили своей целью лаконичный и понятный синтаксис, быструю компиляцию кода и типобезопасность. Язык пока находится в предрелизном состоянии, но всё стремительно движется к релизу.

К слову, после Java «переучиться» на Kotlin не составит никакого труда, в этом поможет и понятный (субъективно) синтаксис, и полная совместимость с кодом на Java в обе стороны, что позволяет Java-программисту использовать весь привычный набор библиотек.

Ещё одной целью разработчиков языка была возможность его гибкого использования, в том числе для создания библиотек, внешне похожих на DSL, и собственных конструкций (хороший пример типобезопасного builder'а для HTML; статья про реализацию yield). У Kotlin есть несколько фич, которые позволят решать эти задачи эффективно и красиво. Давайте с ними познакомимся.