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

Только вручную сделав macroexpand. А в случае реализации шаблона, он раскрывается не по месту вызова, а на верхнем уровне. То есть, если в Common Lisp пытаться делать шаблоны через макросы, то придётся просто выполнять код при раскрытии.
И опять же, даже в лиспе макрос не может переписать кусок AST, который не находится внутри макроса (а, например, просто в этом же файле).

Ну так замену шаблонов надо не макросами делать, а более общим механизмом для переписывания AST, через который можно было бы дописывать в какое-то специально отведенное место результат раскрытия шаблонов (специализации функций и проч). И через этот же механизм можно и обычные макросы как в лиспе реализовать.

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

А каким боком раскрытие шаблонов к оптимизации? Это проблемы оптимизатора конкретного компилятора, чтобы он что-то там сумел оптимизировать, разве шаблоны дают какие-то подсказки в плане оптимизации? Допустим есть некий шаблон, результат раскрытия которого такой-то, такой же результат можно получить вручную, т.е. фактически руками написав код раскрытия (или написав свой препроцессор для этого), проделав работу за компилятор. Разве компилятор и в том и в другом случае не имеет равные возможности что-то заинлайнить?

Слабо на макросах Common Lisp сделать классы Си++?

Это лучше на переписывании AST делать.

Заменить ядро компилятора на лиспоподобное не выкинув половину оптимизаций – крайне сложно.

Оптимизаций раскрытия шаблонов? А в чем выражаются подобные оптимизации? Ну допустим вместо честного раскрытия шаблонов мы это раскрытие сделаем неким внешним препроцессором, как это помешает что-либо оптимизировать? Можно конечно какие-то хинты для компилятора генерить, типа «вот это инлайнить», «вот тут можно сделать так-то» или еще что-то вроде этого

Только вручную сделав macroexpand. А в случае реализации шаблона, он раскрывается не по месту вызова, а на верхнем уровне. То есть, если в Common Lisp пытаться делать шаблоны через макросы, то придётся просто выполнять код при раскрытии.
И опять же, даже в лиспе макрос не может переписать кусок AST, который не находится внутри макроса (а, например, просто в этом же файле).

Ну так замену шаблонов надо не макросами делать, а более общим механизмом для переписывания AST, через который можно было бы дописывать в какое-то специально отведенное место результат раскрытия шаблонов. И через этот же механизм можно и обычные макросы как в лиспе реализовать.

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

А каким боком раскрытие шаблонов к оптимизации? Это проблемы оптимизатора конкретного компилятора, чтобы он что-то там сумел оптимизировать, разве шаблоны дают какие-то подсказки в плане оптимизации? Допустим есть некий шаблон, результат раскрытия которого такой-то, такой же результат можно получить вручную, т.е. фактически руками написав код раскрытия (или написав свой препроцессор для этого), проделав работу за компилятор. Разве компилятор и в том и в другом случае не имеет равные возможности что-то заинлайнить?

Слабо на макросах Common Lisp сделать классы Си++?

Это лучше на переписывании AST делать.

Заменить ядро компилятора на лиспоподобное не выкинув половину оптимизаций – крайне сложно.

Оптимизаций раскрытия шаблонов? А в чем выражаются подобные оптимизации? Ну допустим вместо честного раскрытия шаблонов мы это раскрытие сделаем неким внешним препроцессором, как это помешает что-либо оптимизировать? Можно конечно какие-то хинты для компилятора генерить, типа «вот это инлайнить», «вот тут можно сделать так-то» или еще что-то вроде этого