Представьте себе пятиэтажный дом без лифта, построенный в конце пятидесятых, где-нибудь на отшибе Автозаводской, или еще лучше – в Купчино. Каждый этаж использует свой язык со своей записью. Не в переносном, а в самом прямом смысле: первый этаж общается кириллицей, второй – латиницей, третий – иероглифами, четвертый – клинописью, а пятый, подобно Витгенштейну, принципиально молчит, полагая, что о чем невозможно говорить, о том следует молчать. Почтальон, доставляющий корреспонденцию, вынужден нести пять экземпляров одного и того же письма, переведенного на каждый из этих языков, и каждый раз стучаться в дверь, надеясь, что адресат не переехал на другой этаж.
Именно так устроен мир программирования, если посмотреть на него из-за кулис, а не из партера. У каждого языка – свое внутреннее представление кода. Питон хранит свой AST, как бережливая домохозяйка хранит крупу: в аккуратных контейнерах с этикетками BinOp, FunctionDef, Name. Эликсир, в свойственной ему самоуверенной манере, использует тройки {атом, метаданные, дети} и называет это quoted expressions, словно перед нами не синтаксическое дерево, а собрание цитат из Мандельштама. Ruby складирует свои S-выражения, как букинист – пожелтевшие тома, а Erlang, верный традициям, разговаривает на языке кортежей и атомов, понятном лишь инженерам Ericsson и, по странному стечению обстоятельств, аспирантам нескольких шведских университетов.
Проблема очевидна любому, кто хоть раз пытался написать инструмент для анализа кода. Допустим, вы создали превосходный анализатор цикломатической сложности для Python. Он великолепен: находит вложенные условия, считает точки ветвления, рисует графы потоков управления. Затем к вам приходит коллега и спрашивает: «А для Ruby сделаешь?» И тут выясняется, что весь ваш труд – все эти обходчики деревьев, все эти паттерн-матчинги над питоновским AST – нужно переписать заново. С нуля. Для другого дерева, с другими узлами, другой семантикой и другими подводными камнями. А потом придет третий коллега и попросит то же самое для Haskell.
Представьте себе дирижера, вынужденного заново учить нотную грамоту каждый раз, когда в оркестр приходит новый инструмент. Скрипка – одна система записи. Виолончель – другая. Гобой – третья, причем с обратной полярностью. Труба вообще отказывается признавать существование нотного стана и настаивает на табулатуре собственного изобретения. Абсурд, разумеется. В реальном мире все инструменты читают одну и ту же партитуру. Ноты, ритм, динамика – едины. Различается лишь техника исполнения.
MetaAST – это партитура.
Прежде чем перейти к деталям (а они заслуживают внимания, как заслуживает его хорошо выстроенный детективный сюжет), позвольте сделать небольшое отступление в сторону теории. Для пятилетних Лайманов: никаких формул, одни сплошные аналогии. Впрочем, одна формула все-таки будет, но она настолько элегантна, что не процитировать ее было бы преступлением перед эстетикой.
В начале двухтысячных – когда мобильные телефоны уже существовали, но еще не управляли нашими жизнями – консорциум OMG (Object Management Group, не имеющий никакого отношения ни к божественному, ни к восклицательному) выпустил стандарт под названием MOF: Meta-Object Facility. Суть его укладывается в четыре строчки, но на понимание этих четырех строчек у индустрии ушло два десятилетия. MOF определяет четырехуровневую иерархию моделей:
M⁰ – это работающий код. Вот он бежит, выплевывает результаты, падает с ошибками, потребляет память. Это – реальность.
M¹ – модель реальности. Для программ это AST: абстрактное синтаксическое дерево. Питоновский BinOp(op=Add(), left=Name('x'), right=Num(5)) – это M1. Эликсировское {:+, [context: Elixir], [{:x, [], Elixir}, 5]} – тоже M1. Каждый язык описывает свой код на своем M1, как каждый художник рисует яблоко по-своему.
M² – модель моделей. Мета-модель. Она определяет, чем может быть узел любого AST. Не конкретный узел конкретного языка, а концепция узла. Бинарная операция – это не питоновский BinOp и не эликсировский {:+, ...}. Бинарная операция – это идея того, что два операнда связаны оператором. UML живет на уровне M2. И MetaAST – тоже.
M³ – мета-мета-модель. То, что определяет, чем могут быть сами мета-модели. Система типов, правила композиции. Здесь живет MOF. В контексте MetaAST эту роль играет система типов.
Принципиальное отличие MetaAST от LLVM IR, Java bytecode, или любого другого промежуточного представления состоит именно в этом: все перечисленные – модели (M¹). Они описывают конкретный код в конкретном формате. MetaAST – мета-модель (M²). Она описывает, какими могут быть описания кода. Разница примерно такая же, как между словарем и языком: словарь фиксирует слова, а язык определяет правила, по которым эти слова вообще возможны.
Metastatic – библиотека на Elixir, которая реализует эту идею в коде. Название, как положено приличному техническому проекту, заряжено двойным смыслом: Met(a)-AST-atic, то есть «принадлежащий мета-уровню AST». Медицинские коннотации – за счет заведения.
Архитектура трехслойная, и это не прихоть, а следствие теории:
M2.1 – ядро (Core). Концепции, присутствующие в каждом языке программирования на свете. Литералы, переменные, бинарные операции, условия, вызовы функций, присваивания. Здесь нет никакой экзотики. x + 5 на Python, Elixir, Ruby, Erlang и Haskell (те языки, которые поддерживаются в той или иной степени на данный момент) – это одно и то же. Одинаковое MetaAST-представление. Буквально:
{:binary_op, [category: :arithmetic, operator: :+], [{:variable, [], "x"}, {:literal, [subtype: :integer], 5}]}
Пять языков. Одно дерево. Один инструмент анализа. Партитура, читаемая любым инструментом оркестра.
M2.2 – расширения (Extended). Конструкции, существующие в большинстве языков, но не во всех. Циклы, лямбды, операции над коллекциями, паттерн-матчинг, обработка исключений. Haskell не знает императивных циклов – ну и бог с ним: для него есть рекурсия на уровне M2.1. Ruby не знает guards – не беда: метаданные адаптера сохранят контекст.
M2.3 – нативный слой (Native). Аварийный выход для конструкций, которые не поддаются обобщению. Rust’овские лайфтаймы, Haskell’овские type classes, эликсировское метапрограммирование. Они оборачиваются в {:language_specific, :rust, ...} – как хрупкий фарфор в пупырчатую пленку – и путешествуют через систему, не теряя своей идентичности, но и не претендуя на универсальность.
Каждый узел MetaAST – тройка. Тип, метаданные, дети (или значение). Формат сознательно скопирован с эликсировских quoted expressions, потому что если вы уже умеете писать макросы в Elixir, вы уже умеете работать с MetaAST. Разница в семантике: где Elixir использует :+ (сам оператор), MetaAST использует :binary_op (концепцию бинарной операции), а оператор убирает в метаданные. Где Elixir инлайнит литералы, MetaAST оборачивает их в {:literal, [subtype: :integer], 42}, обеспечивая структурную однородность.
Языковые адаптеры – мост между M1 и M2. Адаптер для Python берет питоновский AST (полученный через subprocess) и абстрагирует его до MetaAST. Адаптер для Elixir берет quoted expressions и делает то же самое. Адаптер для Ruby – аналогично. Обратная операция – реификация – превращает MetaAST обратно в нативный AST целевого языка. Эта пара операций, абстракция и реификация, образует то, что математики называют связью Галуа:
Adapter_L = (alpha_L, rho_L)alpha_L: AS_L -> MetaAST x Metadata (абстракция: M1 -> M2)rho_L: MetaAST x Metadata -> AS_L (реификация: M2 -> M1)
Что это означает на практике? Вот вам сценарий. Вы написали анализатор чистоты функций. Он работает с MetaAST: обходит дерево, ищет побочные эффекты (ввод-вывод, мутацию состояния, обращения к случайным числам), и выносит вердикт. Этот анализатор написан один раз. Один. И он работает с Python, Elixir, Ruby, Erlang и Haskell. Потому что анализирует не питоновский или эликсировский AST, а мета-уровень. Вы пишете:
{:ok, doc} = Metastatic.Adapter.abstract(Python, "print('hello')", :python){:ok, result} = Metastatic.Analysis.Purity.analyze(doc)result.pure? # => false -- побочный эффект: ввод-выводresult.effects # => [:io]
И ровно тот же код, без изменений, работает, если заменить Python на Ruby, а print('hello') на puts 'hello'. Потому что оба вызова – это {:function_call, [name: "print"], [{:literal, [subtype: :string], "hello"}]} на уровне M2.
Главный API библиотеки нарочито прост. Две функции: Metastatic.quote/2 и Metastatic.unquote/2. Первая поднимает исходный код с уровня исходного текста до MetaAST (Source -> M1 -> M2). Вторая опускает обратно (M2 -> M1 -> Source). Между этими двумя вызовами живет вся магия: анализ, трансформация, обнаружение дупликатов, проверка эквивалентности.
# Парсим Python{:ok, py_ast} = Metastatic.quote("x + 5", :python)# Генерируем Elixir -- тот же MetaAST, другой язык{:ok, elixir_source} = Metastatic.unquote(py_ast, :elixir)# => "x + 5"
Кросс-языковая трансляция – не главная цель (хотя и она впечатляет). Главная цель – кросс-языковой анализ. Metastatic предоставляет девять встроенных анализаторов, двадцать бизнес-логических детекторов антипаттернов, обнаружение клонов кода четырех типов (от точных копий до семантических), граф потока управления, анализ taint-уязвимостей. И все это работает на любом поддерживаемом языке, потому что работает на мета-уровне.
Обнаружение дупликатов – отдельное удовольствие. Представьте: у вас есть Python-модуль и Ruby-класс, написанные разными людьми, в разное время, в разных часовых поясах. Metastatic находит, что их MetaAST совпадает на 94%, – это клон второго типа (различаются только имена переменных). Факультет зеркальных близнецов, разделенных при рождении языковым барьером.
{:ok, result} = Metastatic.Analysis.Duplication.detect(python_doc, ruby_doc)result.clone_type # => :type_iiresult.similarity_score # => 0.94
Вернемся к MOF и четырехуровневой иерархии. Зачем все это нужно? Зачем городить мета-модели, если можно просто написать конвертер из одного AST в другой?
Ответ прост и ироничен, как правда жизни. Конвертер работает попарно. Для пяти языков нужно двадцать конвертеров (5 × 4). Для десяти – девяносто. Для двадцати – триста восемьдесят. Мета-модель работает через хаб: каждый язык подключается один раз, через свой адаптер. Пять языков – пять адаптеров. Десять – десять. Двадцать – двадцать. Линейный рост вместо квадратичного. Математик, проработавший полжизни на конвейере, оценил бы иронию.
Но дело не только в комбинаторике. Мета-модель дает стандартизацию. Каждый инструмент, написанный для MetaAST, гарантированно работает с любым языком, для которого существует адаптер. Это не «поддержка Python» и «поддержка Ruby» как отдельные фичи. Это одна фича: поддержка MetaAST. Все остальное – следствие.
OMG понял это в 2002 году, когда выпустил MOF. Индустрия UML построена на том же принципе: мета-модель определяет, чем могут быть модели, а конкретные диаграммы – лишь экземпляры этой мета-модели. MDA (Model-Driven Architecture) развил идею дальше: трансформации между моделями определяются на мета-уровне и автоматически применяются к любым экземплярам.
Metastatic делает то же самое, но не для диаграмм классов, а для синтаксических деревьев программ. Это не IR, не компилятор, не транспайлер. Это фундамент, на котором все перечисленное может быть построено – один раз, и для всех языков сразу.
Есть старая история про оливковое дерево, которую мне однажды рассказал некий журналист в самолете. Человек всю жизнь выращивает оливу, а дерево, наконец выросшее, приносит маслины. Человек не знает, что оливы и маслины – это одно и то же. Он считает свою жизнь потраченной впустую.
AST разных языков – это маслины. MetaAST – это знание о том, что все они растут на одном дереве. Разница между ними – терминологическая, а не семантическая. Питоновский BinOp(op=Add()), эликсировский {:+, [], [...]} и руби-нодовский s(:send, ..., :+, ...) – разные названия одного и того же: {:binary_op, [category: :arithmetic, operator: :+], [left, right]}.
Можно, конечно, прожить всю жизнь, переписывая инструменты для каждого нового языка. Можно каждый раз заново учить нотную грамоту, кланяться каждому новому инструменту оркестра, переводить письма на пять языков для пяти этажей одного и того же дома. Но зачем, если можно подняться на один уровень абстракции – туда, где оливы и маслины неразличимы, а партитура одна на всех?
Ну вот MetaAST – шаг в этом направлении.
ссылка на оригинал статьи https://habr.com/ru/articles/1024412/