Должны ли макросы иметь побочные эффекты?

Краткий ответ

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

Более длинный ответ

Макросы с побочными эффектами являются мощным инструментом и могут позволить вам делать то, что значительно упрощает написание программ, или делать то, что вообще невозможно. Но есть подводные камни, о которых следует помнить, когда вы используете побочные эффекты в макросах. К счастью, Racket предоставляет все инструменты, чтобы убедиться, что вы можете сделать это правильно.

Самый простой вид побочного эффекта макроса — это когда вы используете какое-то внешнее состояние для поиска кода, который хотите сгенерировать. Примеры, которые вы перечисляете в вопросе (чтение описания API Google), относятся к этому типу. Еще более простой пример — макрос include:

#lang racket
(include "my-file.rktl")

Это считывает содержимое myfile.rktl и размещает его прямо там, где используется форма include.

Итак, include - не лучший способ структурировать вашу программу, но это вполне безобидный побочный эффект в макросе. Это работает так же, если вы скомпилируете файл заранее, как если бы вы этого не делали, поскольку результат include является частью файла.

Другой простой пример, который не очень хорош, выглядит примерно так:

#lang racket
(define-syntax (show-file stx)
  (printf "using file ~a\n" (syntax-source stx))
  #'(void))

(show-file)

Это связано с тем, что printf выполняется только во время компиляции, поэтому, если вы скомпилируете свою программу, которая использует show-file заранее (как с raco make), тогда printf произойдет тогда, а не во время запуска программы, что, вероятно, не так. т намерение.

К счастью, в Racket есть техника, позволяющая эффективно писать макросы типа show-file. Основная идея состоит в том, чтобы оставить остаточный код, который фактически выполняет побочный эффект. В частности, для этой цели вы можете использовать форму Racket begin-for-syntax. Вот как я бы написал show-file:

#lang racket
(define-syntax (show-file stx)
  #`(begin-for-syntax
      (printf "using file ~a\n" #,(syntax-source stx))))

(show-file)

Теперь вместо расширения макроса show-file printf происходит в коде, который show-file создает, с исходным кодом, встроенным в расширенный синтаксис. Таким образом, ваша программа будет работать корректно даже при предварительной компиляции.

Есть и другие варианты использования макросов с побочными эффектами. Одним из наиболее заметных в Racket является взаимодействие между модулями — поскольку require не создает значений, которые может получить требующий модуль, наиболее эффективным способом взаимодействия между модулями является использование побочных эффектов. Чтобы заставить это работать при наличии компиляции, требуется почти такой же трюк с begin-for-syntax.

Это тема, над которой сообщество Racket, и я в частности, много думали, и есть несколько академических статей, в которых рассказывается, как это работает:

Компонуемые и компилируемые макросы: нужно когда?< /a>, Мэтью Флэтт, ICFP 2002

Расширенная макрология и реализация типизированной схемы< /a>, Райан Калпеппер, Сэм Тобин-Хохштадт и Мэтью Флэтт, Scheme Workshop 2007

Языки как библиотеки, Сэм Тобин-Хохштадт, Райан Калпеппер, Винсент Сент-Амур, Мэтью Флэтт и Матиас Феллейзен, PLDI 2011

В обычном Лиспе функция eval-when позволяет вам решить, когда макрос будет раскрыт.