История изменений

Собственно проблема кодогенерации вообще и макросов в частности именно в этом, как по мне, что у тебя инструмент превращается в непоймичо и это непоймичо надо расковыривать отдельно. А сделать так, чтобы было композабельно и при этом не требовало лезть внутрь сделать могут немногие. Ну и остальное уже не единожды упоминали, что если в лиспах макросинг это нормальный путь, потому что у тебя весь синтаксис это AST жопой к программисту, то в том же расте у тебя есть обычные макросы с наркоманским синтаксисом и proc-macro, которые считай трансформер token stream непоймичего в растовый token stream.

Действительно. Вот и ответ. Макросы в стиле лиспа сложно отлаживать и поддерживать в IDE. Как я уже писал, единственное исключение Racket, но в нём как раз при выборе между макросом и функцией всегда выбирают функцию.

Макросы в стиле лиспа в общем случае сложно писать. По крайней мере, практически везде, кроме самого Common Lisp, есть альтернативный «простой» путь написания макросов (как обычные макросы в расте).

Макросы в стиле лиспа являются протекающей абстракцией, так как используемый в них символы могут иметь не то значение, которое ожидается, в момент применения. Где-то с этим борются вводя гигиену (и заметно усложняя макросы, так как теперь каждый узел тащит контекст), где-то (как в Common Lisp) просто запоминают, где грабли.

Для макроса в стиле лиспа аргументы макроса должны быть корректными синтаксическими деревьями. Это ограничивает возможный синтаксис. И если в лиспе ограничение не так заметно, так как все синтаксические структуры и так имеют вид последовательности элементов в скобках, то для других языков почти всегда невозможно сделать ещё один if. Приходится делать что-то вроде if2(cond(), { do_if_true(); }, { do_if_false(); });, что ужасно некрасиво.

Собственно проблема кодогенерации вообще и макросов в частности именно в этом, как по мне, что у тебя инструмент превращается в непоймичо и это непоймичо надо расковыривать отдельно. А сделать так, чтобы было композабельно и при этом не требовало лезть внутрь сделать могут немногие. Ну и остальное уже не единожды упоминали, что если в лиспах макросинг это нормальный путь, потому что у тебя весь синтаксис это AST жопой к программисту, то в том же расте у тебя есть обычные макросы с наркоманским синтаксисом и proc-macro, которые считай трансформер token stream непоймичего в растовый token stream.

Действительно. Вот и ответ. Макросы в стиле лиспа сложно отлаживать и поддерживать в IDE. Как я уже писал, единственное исключение Racket, но в нём как раз при выборе между макросом и функцией всегда выбирают функцию.

Макросы в стиле лиспа в общем случае сложно писать. По крайней мере, практически везде, кроме самого Common Lisp, есть альтернативный «простой» путь написания макросов (как обычные макросы в расте).

Макросы в стиле лиспа являются протекающей абстракцией, так как используемый в них символы могут иметь не то значение, которое ожидается, в момент применения. Где-то с этим борются вводя гигиену (и заметно усложняя макросы, так как теперь каждый узел тащит контекст), где-то (как в Common Lisp) просто запоминают, где грабли.

Для макроса в стиле лиспа аргументы макроса должны быть корректными синтаксическими деревьями. Это ограничивает возможный синтаксис. И если в лиспе ограничение не так заметно, так как все синтаксические структуры и так имеют вид последовательности элементов в скобках, то для других языков почти всегда невозможно сделать ещё один if. Приходится делать что-то вроде if2(cond(), { do_if_true(); }, { do_)if_false(); });, что ужасно некрасиво.