Вот тут http://www.linux.org.ru/view-message.jsp?msgid=3080272#3088381 ответили, старая тема не работает. Поэтому заводим новую.
Отвечаю на Схему. Лисп, как известно, динамически типизирован. Это ведёт к проблемам с производительностью. И если в sbcl за счёт тщательной работы с декларациями типов почти удаётся догнать С (а иногда и обогнать), то у Схемы нет никаких шансов, т.к. декларации типов в ней не предусмотрены. Это - первое. Второе: сборка мусора. Совсем не подходит для многих задач, и тоже замедляет работу во многих случаях. Третье: иногда программа должна быть маленькой. Например, это может быть программа, которая неряшливо открывает файлы. Чтобы их закрыть, достаточно убить программу, тогда операционная система закроет файлы сама. Эту программу мы будем вызывать из лиспа. Или нужна программа для мобильного устойства, где мегабайт рантайма - это уже много. А мощная схема имеет как раз примерно такой рантайм.
В том, что я хотел сделать, всё гораздо проще - от лиспа берётся синтаксис, от С - семантика. Т.е., к примеру, такие вещи, как GObject (сам не видел, но говорят, там нужно много копипастить) становятся (в идеале) лёгкими в обращении за счёт метапрограммных средств лиспа.
Лисп характерен тем, что в нём есть естественное представление AST и множество механизмов (удобной) работы с ними. Вот этим и предлагается воспользоваться. Потому что от синтаксиса С до AST - расстояние очень небольшое.
Вот есть, к примеру, проект opencxx. Но cxx меня в принципе не интересует, т.к.... ладно, молчу. В общем, не интересует. Поэтому, целевой проект - гораздо проще - openc. C с промежуточным слоем в виде AST. AST представлены и трансформируются в лиспе. А чтобы не мучаться с транслятором C->AST, мы просто сразу пишем в терминах AST, поскольку верим, что это удобнее.
Такой проект вполне реализуем одним человеком за ограниченное время. В общем-то, я уже реализовывал работоспособную и отчасти даже полезную часть такого проекта для скриптовых языков SQL, на которых пишутся хранимые процедуры. Из-за половинчатого подхода к реализации (генерил я всё же текст, а не AST) получилось не очень хорошо. Впрочем, если пытаться SQL перевести на AST а потом на этом AST ещё и разрабатывать прикладной код, вполне можно повредиться умом. Поэтому именно для SQL возможность генерации именно текста, а не AST, как раз кажется более верной (хм, кстати, это забавная мысль...) В итоге я получил SQL с макросами и уложился в 100 кб исходников самого генератора. И (при должной степени фанатизма) можно убедить себя в том, что внедрение этого генератора было скорее полезно, чем вредно.
Реализовать же компилятор со схемы или (боже упаси) CL на С - это значит столкнуться с массой проблем либо перетащить проблемы лиспа в новое приложение на С. Даже применять уже существующий компилятор - это тоже трабл. Приложения лиспа тяжеловесны и стабильны. Приложения на С - легки и часто падают. Попытка их скрестить именно в грубом физическом смысле слова, бездуховно, приводит к сочетанию худших качеств: приложение получается тяжёлым и падучим. А вот если применить святой дух (барьер метатрансформации или хотя бы взаимодействие через IPC), то тогда уже получается лучше.
