Кстати, я же правильно понимаю, что макросы(fexpr) можно и нужно

"разворачивать" на этапе генерации байткода. Тоесть основные (lambda if define ...) будут иметь свои инструкции байткода, а остальные будут в них преобразовываться? Просто иначе как мне кажется получится не очень красиво

Строго говоря, никакого compile-time у Scheme нет, и все макросы вызываются в run-time, т.е. во время выполнения байт-кода. Часть макросов можно "развернуть" и во время "компиляции". Но не все. Какие-то макросы могут вообще никогда не вызываться, но производить побочные эффекты при разворачивании.

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

Пусть у нас есть определение функции frob. В её теле содержится макрос x. Для того, чтобы сгенерировать байткод функции frob нужно выполнить макрос x. К примеру, выполнив байткод макроса x

В смысле? Макрос же может вызывать обычные функции, которые уже должны быть скомпилированы в байт-код, а теперь, стало быть, проинтерпретипованы, чтобы получить результат и вставить в макрос? Вы же знаете про quasi-quotes, splice и вот это всё?

Уже вроде бы понял, что как сказали выше компиляцию и интерпретацию прийдётся смешивать. А quasi-quotes вроде появились в более поздних схемах

Я вот сейчас закончил с некоторыми базовыми вещами(lambda, if, define ) и вернулся к пользовательским макросам. Вобщем, можете пожалуйста объяснить о каких побочных эффектах идёт речь и что подразумевается под разворачиванием(может я просто не правильно понимаю)? Просто я немного прошерстил гугл и везде написано совсем разное, guile вроде выделяет отдельный этап: "Macro expansion is a separate phase of evaluation, run before code is interpreted or compiled", где-то пишут, что рантайм и макросы это несовместимые понятия. Не могу разобраться до конца. В "scheme in 48 hours" не нашел этой информации.

Тут два варианта. Если Вы хотите реализовать именно RnRS (for a particular choice of n) — делайте ровно так, как написано в его операционной семантике (для baseline, потом можно попробовать "срезать углы", если это не противоречит семантике). Если Вы хотите сделать "качественные гигиенические макросы" вообще — делайте как в Racket, на эту тему есть довольно подробные статьи (но писец сложные для понимания... 😒).

Скорее второй вариант. Статьи я конечно почитаю, но честно макрология схем выглядит страшненько.

В целом, макрос — это такая штука, которая берёт некоторый код (AST или несколько) и производит другой код (снова AST, который подставляется (концептуально) на место вызова макроса). Так вот, в процессе этого самого "производит другой код" макрос может вызывать произвольный "обычный" код (и макросы тоже), который может делать что угодно, в том числе читать-писать глобальные переменные, файлы, сетевые сокеты и т.д. Это называется "производить побочные эффекты".

https://dl.acm.org/doi/abs/10.1145/2914770.2837620 Если разберётесь как это работает — объясните и мне, пожалуйста... 😏

Там, конечно, самый большой источник сложности — первоклассные модули, которых в "ванильном" Scheme (да и почти нигде больше) нет.

Так, тоесть если какой-то макрос A, вызывает функцию B, которая в своем теле например делает (DEFINE X 10) будет производить побочный эффект? Просто я думал под побочным эффектом подразумевается тоже самое, но не при вызове, а при объявлении. А учитывая всякие динамические окружения и подобные прелести разве действие макроса A вообще является неожиданным? Тоесть почему устранение подобного вообще необходимо(в r1rs этот момент к сожалению не рассматривается насколько я вкурсе)

Звучит обнадеживающе)

У динамических языков «компил-таймом», по сути, является и кусочек рантайма на этапе инстанцирования и интциализации всех модулей? Можно сказать, что динамический язык является собственным загрузчиком и макро(мета)языком до «заморозки» своих динамических объектов (в ЖС, например, есть метод .freeze), до вызова какого-нибудь .run() :3