Метапрограммирование

Символ : имеет в Julia две синтаксических функции. Первая форма создает Symbol, сохраненную строку, используемую как один строительный блок выражений, на основе допустимых имен:

Конструктор Symbol принимает любое количество аргументов и создает новый символ путем конкатенации представления их строк:

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

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

Вторая синтаксическая функция символа : — создавать объекты выражения без явного использования конструктора Expr. Это называют цитированием. Символ :, за которым следует пара скобок вокруг одного выражения кода Julia, производит объект Expr на основе включенного кода. Вот пример краткой формы, используемой для цитирования арифметического выражения:

(чтобы просмотреть структуру этого выражения, попробуйте ex.head и ex.args или используйте dump, как показано выше, или Meta.@dump)

Обратите внимание, что эквивалентные выражения можно сконструировать с помощью Meta.parse или прямой формы Expr:

Выражения, предоставленные анализатором, обычно имеют в качестве своих аргументов только символы, другие выражения и литеральные значения, в то время как выражения, сконструированные кодом Julia, могут иметь произвольные переменные времени выполнения без литеральных форм в качестве аргументов. В этом конкретном примере + и a являются символами, *(b,c) — подвыражением, а 1 — литеральным 64-разрядным целым числом со знаком.

Существует вторая синтаксическая форма цитирования для нескольких выражений: блоки кода, заключенные в quote ... end.

Непосредственное конструирование объектов Expr с аргументами значений эффективно, но использование конструкторов Expr может быть утомительным по сравнению с «нормальным» синтаксисом Julia. В качестве альтернативы Julia разрешает интерполяцию литералов или выражений в цитируемые выражения. Интерполяция обозначается префиксом $.

В этом примере значение переменной a интерполируется:

Интерполяция в нецитируемое выражение не поддерживается и будет вызывать ошибку времени компиляции:

В этом примере кортеж (1,2,3) интерполируется как выражение в проверку условия:

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

Заметьте, что синтаксис интерполяции $ разрешает вставку только одного выражения во включающее выражение. В некоторых случаях у вас есть массив выражений, и вам нужно, чтобы все они стали аргументами окружающего выражения. Это можно сделать с помощью синтаксиса $(xs...). Например, следующий код создает вызов функции, в котором число аргументов определяется программно:

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

Заметьте, что результат содержит $x, что означает, что x еще не был вычислен. Другими словами, выражение $ «принадлежит» внутреннему выражению цитирования, и поэтому его аргумент вычисляется, только когда внутреннее выражение цитирования следующее:

Однако внешнее выражение quote может интерполировать значения внутри $ во внутреннем цитировании. Это делается с помощью нескольких $:

Заметьте, что в результате теперь отображается (1 + 2), а не символ x. Вычисление этого выражения выдает интерполированное 3:

Интуиция, лежащая в основе этого поведения, состоит в том, что x вычисляется один раз для каждого $: один $ работает аналогично eval(:x), присваивая значение x, в то время как два $ выполняют эквивалент eval(eval(:x)).

Обычное представление цитирования (quote) в AST — это Expr с заголовком :quote:

Как мы увидели, такие выражения поддерживают интерполяцию с $. Однако в некоторых ситуациях необходимо цитировать код без выполнения интерполяции. Этот вид цитирования еще не имеет синтаксиса, но имеет внутреннее представление как объект типа QuoteNode:

Анализатор выдает QuoteNode для простых процитированных элементов, таких как символы:

QuoteNode также можно использовать для определенных сложных в реализации задач метапрограммирования.

Если имеется объект выражения, можно сделать так, чтобы среда Julia вычисляла (выполняла) его в глобальной области с помощью eval:

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

Здесь вычисление объекта выражения приводит к присваиванию значения глобальной переменной x.

Так как выражения — это просто объекты Expr, которые можно сконструировать программно, а затем вычислить, возможно ли динамически создавать произвольный код, который затем можно выполнить с помощью eval. Вот простой пример.

Значение a используется для конструирования выражения ex, которое применяет функцию + к значению 1 и переменной b. Обратите внимание на важное различие между тем, как используются a и b:

Как замечено выше, одной из чрезвычайно полезных функций Julia является возможность генерировать код Julia и манипулировать им в самом языке Julia. Мы уже видели один пример функции, возвращающей объекты Expr: функцию parse, которая принимает код Julia и возвращает соответствующий Expr. Функция также может принимать один или несколько объектов Expr в качестве аргументов и возвращать еще один Expr. Вот простой мотивирующий пример.

Приведем другой пример. Вот функция, которая удваивает любой числовой аргумент, но оставляет выражения нетронутыми:

Вот чрезвычайно простой макрос:

У макросов в синтаксисе Julia есть выделенный символ: @ (коммерческое at), за которым следует объявленное в блоке macro NAME ... end. В этом примере компилятор заменит все экземпляры @sayhello на:

Когда @sayhello вводится в REPL, выражение выполняется немедленно, таким образом, мы видим только результат вычисления:

Теперь рассмотрим немного более сложный макрос:

Этот макрос принимает один аргумент: name. Если встречается @sayhello, цитируемое выражение расширяется, чтобы интерполировать значение аргумента в окончательном выражении:

Мы можем просмотреть возвращенное цитируемое выражение с помощью функции macroexpand (важное замечание: это чрезвычайно полезный инструмент для отладки макросов):

Можно видеть, что литерал "human" интерполирован в выражение.

Также существует макрос @macroexpand, который, возможно, немного удобнее функции macroexpand:

Мы уже видели функцию f(::Expr...) -> Expr в предыдущем разделе. На самом деле macroexpand — тоже такая функция. Так почему существуют макросы?

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

Первый вызов println выполняется, когда вызывается macroexpand. Результирующее выражение содержит только второе println:

Макросы вызываются с помощью следующего общего синтаксиса:

Обратите внимание на отличительное @ перед именем макроса, отсутствие запятых между выражениями аргумента в первой форме и отсутствие пробела после @name во второй. Эти два стиля не следует смешивать. Например, следующий синтаксис отличается от примеров выше; он передает кортеж (expr1, expr2, ...) как один аргумент в макрос:

Альтернативный способ вызова макроса для литерала массива (или включения) — противопоставить одно другому без использования скобок. В этом случае массив будет единственным выражением, передаваемым макросу. Следующий синтаксис является эквивалентным (и отличным от @name [a b] * v):

Важно подчеркнуть, что макросы получают свои аргументы как выражения, литералы или символы. Одним из способов изучить аргументы макроса является вызов функции show в теле макроса:

В добавление к заданному списку аргументов каждому макросу передаются дополнительные аргументы с именами __source__ и __module__.

Аргумент __source__ предоставляет информацию (в форме объекта LineNumberNode) о расположении анализатора знака @ из вызова макроса. Это позволяет макросам включать более качественную информацию о диагностике ошибок и обычно используется, например, ведением журналов, макросами анализа строк и документами, а также для реализации макросов @__LINE__, @__FILE__ и @__DIR__.

К сведениям о расположении можно получить доступ, сославшись на __source__.line и __source__.file:

Аргумент __module__ предоставляет информацию (в форме объекта Module) о контексте расширения вызова макроса. Это позволяет макросу искать информацию о контексте, такую как существующие связи, или вставлять значение как дополнительный аргумент в вызов функции во время выполнения, осуществляющей самопроверку в текущем модуле.

Вот упрощенное определение макроса @assert Julia:

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

Вместо записанного синтаксиса макрос расширяется во время анализа до его возвращаемого результата. Это эквивалентно следующей записи:

То есть в первом вызове выражение :(1 == 1.0) вплетается в слот условия теста, в то время как значение string(:(1 == 1.0)) вплетается в слот сообщения утверждения. Все выражение, сконструированное таким образом, помещается в синтаксическое дерево, в котором происходит вызов макроса @assert. Затем во время выполнения, если при вычислении тестового выражения оно получает значение true, то возвращается nothing, тогда как если значение — false, выдается ошибка, указывающая на то, что утверждаемое выражение имело значение false. Заметьте, что невозможно записать это как функцию, так как доступно только значение условия, и невозможно отобразить выражение, которое вычислило его, в сообщении об ошибке.

Фактическое определение @assert в Julia Base более сложное. Оно позволяет пользователю указывать собственные варианты сообщений об ошибках, а не просто выводить на экран выражение со сбоем. Так же как и в функциях с переменным число аргументов (Функции с переменным числом аргументов (Vararg)), это обозначается многоточием после последнего аргумента:

Теперь @assert имеет два режима работы в зависимости от количества получаемых аргументов! Если имеется только один аргумент, кортеж выражений, захватываемый msgs, будет пустым и будет вести себя так же, как и приведенное выше более простое определение. Но теперь, если пользователь указывает второй аргумент, он выводится на экран в теле сообщения, а не в выражении, завершившемся сбоем. Вы можете изучить результаты макрорасширения с соответствующим образом названным макросом @macroexpand:

Есть еще один случай, который обрабатывает макрос @assert: что если помимо вывода на экран «a должно равняться b» мы хотим вывести их значения? Можно наивно попытаться использовать строковую интерполяцию в пользовательском сообщении, например @assert a==b "a ( b)!", но это не будет работать, как ожидается в приведенном выше макросе. Понимаете, почему? Вспомните, что в разделе Строковая интерполяция говорилось, что интерполированная строка перезаписывается в вызов string. Сравните:

Поэтому теперь вместо получения простой строки msg_body макрос получает выражение целиком, которое необходимо вычислить, чтобы отобразить данные как ожидается. Это может быть вплетено в возвращенное выражение в качестве аргумента вызова string; полную реализацию см. по ссылке error.jl.

Макрос @assert широко использует вплетения в цитируемые выражения, чтобы упростить операции с выражениями внутри тела макроса.

Проблема, которая возникает в более сложных макросах, — это гигиена. Если вкратце, макросы должны гарантировать, что переменные, которые они представляют в возвращенных выражениях, случайно не конфликтуют с существующими переменными в окружающем коде, в который они разворачиваются. И наоборот, от выражений, которые передаются в макрос как аргументы, часто ожидается, что они будут выполнять вычисления в контексте окружающего кода, взаимодействуя с существующими переменными и изменяя их. Другая проблема возникает из-за того факта, что макрос может вызываться в модуле, отличном от того, в котором он был определен. В этом случае нам нужно гарантировать, что все глобальные переменные разрешаются в правильный модуль. В языке Julia уже есть важное преимущество над языками с текстовым макрорасширением (типа C), которое состоит в том, что необходимо рассматривать только возвращенные выражения. Все другие переменные (такие как msg в @assert выше) следуют нормальному поведению блока определения области действия.

Чтобы продемонстрировать эти проблемы, рассмотрим написание макроса @time, который принимает выражение в качестве своего аргумента, записывает время, вычисляет выражение, снова записывает время, выводит на экран разницу между временем до и после, а затем получает значение выражения в качестве окончательного значения. Макрос может выглядеть следующим образом:

Здесь мы хотим, чтобы t0, t1 и val были частными временными переменными, а также чтобы time_ns ссылался на функцию time_ns в Julia Base, а не на какую-либо переменную time_ns, которая может быть у пользователя (то же самое относится к println). Представьте себе проблемы, которые могли бы произойти, если пользовательское выражение ex также содержало бы присваивания переменной с именем t0 или определяло бы собственную переменную time_ns. Мы могли бы получить ошибки или загадочно неправильное поведение.

Макрорасширитель Julia разрешает эти проблемы следующим образом. Во-первых, переменные в результате макроса классифицируются как локальные или глобальные. Переменная считается локальной, если ей присвоено значение (и она не объявлена глобальной), она объявлена локальной или используется в качестве имени аргумента функции. В противном случае она считается глобальной. Локальные переменные затем переименовываются, чтобы быть уникальными (с помощью функции gensym, которая генерирует новые символы), а глобальные переменные разрешаются в среде определения макросов. Следовательно, решаются обе описанные выше проблемы; локальные переменные макроса не будут конфликтовать с какими-либо пользовательскими переменными, а time_ns и println будут ссылаться на определения Julia Base.

Однако одна проблема остается. Рассмотрим следующее использование этого макроса:

Здесь пользовательское выражение ex является вызовом time_ns, но не той же функции time_ns, которую использует макрос. Оно явно ссылается на MyModule.time_ns. Поэтому мы должны сделать так, чтобы код в ex разрешался в среду вызова макросов. Это делается путем добавления к выражению escape-последовательностей esc:

Выражение, обернутое таким образом, остается нетронутым макрорасширителем и просто дословно вставляется в выходные данные. Следовательно, оно будет разрешено в среду вызова макросов.

Этот механизм использования escape-последовательностей при необходимости можно использовать для «нарушения» правил гигиены, чтобы вводить пользовательские переменные или управлять ими. Например, следующий макрос задает для x значение 0 в среде вызова:

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

Правильное формулирование правил гигиены может быть сложнейшей задачей. Перед использованием макроса вам, возможно, захочется рассмотреть, будет ли достаточным замыкание функции. Другая полезная стратегия — отложить как можно больше работы на время выполнения. Например, многие макросы просто оборачивают свои аргументы в QuoteNode или другие подобные Expr. Примерами этого является @task body, который просто возвращает schedule(Task(() -> $body)), и @eval expr, который просто возвращает eval(QuoteNode(expr)).

Для демонстрации мы могли бы переписать пример @time выше следующим образом:

Однако мы этого не делаем, и неслучайно: оборачивание expr в новый блок области (анонимная функция) также слегка меняет значение выражения (область любых переменных в нем), в то время как мы хотим, чтобы @time можно было использовать с минимальным влиянием на обернутый код.

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

Однако следует помнить, что множественная диспетчеризация базируется на типах AST, которые передаются макросу, а не на типах, которые AST вычисляет во время выполнения:

Базовая библиотека Julia имеет внутреннюю функцию sub2ind для вычисления линейного индекса в n-мерном массиве на основе набора n мультилинейных индексов — другими словами, для вычисления индекса i, который можно использовать для индексирования в массиве A с помощью A[i], а не A[x,y,z,...]. Одной из возможных реализаций является следующая:

То же самое можно сделать с помощью рекурсии:

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

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

Какой код будет сгенерирован?

Простой способ это узнать — извлечь тело в другую (регулярную) функцию:

Теперь мы можем выполнить sub2ind_gen_impl и изучить выражение, которое она возвращает:

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

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

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

Внутренне этот код создает две реализации функции: генерируемую, в которой используется первый блок в if @generated, и обычную, где используется блок else. Внутри части then блока if @generated код имеет ту же семантику, что и другие генерируемые функции: имена аргументов ссылаются на типы, а код должен возвращать выражение. Может встречаться несколько блоков if @generated, в каковом случае генерируемая реализация использует все блоки then, а альтернативная реализация использует все блоки else.

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

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