Есть clisp.

Chicken Scheme компилится в Си.

можно и haskell взять, он ничем не хуже и из коробки умеет собираться и в С в том числе. Хотя конечно дело хозяйское если lisp или sсheme ближе, то хозяин - барин.

Нужно для встройки дохрена декларативного кода (различные структурированные данные) в код на C++.

Например?

есть код в виде s-expressions который представляет с собой данные (всякие константы разных типов, включая сложные) и хандлеры событий (таймер, открытие потока, выход и пр.), нужно это все использовать из кода на C++ и C. Сейчас используется встроенный интерпретатор, но в нем накопилось много технического долга и никто уже не понимает как это вообще работает и разбираться не хочет. Соответственно нужно заменить интерпретатор на компилятор и все компилировать в .so и/или .a с последующими изменениями для использования.

Я думаю что после трансляции ситуация станет безнадёжной.

Есть ECL lisp.

+1 кажется это еще более плохая идея, завернуть что не понимаешь в библиотеку. А просто назначить человека на код нельзя есть же вертикаль власти, что вы как не в режимном мире.

Не код на лиспе живой, с интерпретатором бодаться всем надоело, а желающих починить нет.

Есть те, кто понимает что-то в лисповом коде но нет понимающих и желающих понимать код интерпретатора.

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

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

А чего бы не взять какой-нибудь Guile гнутый и его прикрутить?

Соответственно нужно заменить интерпретатор на компилятор и все компилировать в .so и/или .a с последующими изменениями для использования

Т.е. ты хочешь кодогенератор по декларативному описанию. Ничего под твою уникальную задачу ты не найдёшь. Тебе придётся либо писать свой велосипед, либо переписать имеющийся код под существующие кодогенераторы (например c-mera). Так или иначе придётся поработать, а в таком случае, не лучше ли будет вообще выкинуть эту эзотерику и переписать на Си?

PS: если всё-таки возьмёшь химеру, то можешь попробовать наколбасить макросов для трансляции из твоего недолиспа.

есть код в виде s-expressions который представляет с собой данные (всякие константы разных типов, включая сложные) и хандлеры событий (таймер, открытие потока, выход и пр.), нужно это все использовать из кода на C++ и C

А можно ли его переписать скажем на хаскель?

Где-то валялся транслятор прямо s-выражений в синтаксис плюсов. Где — не помню. Но там без макр и всего остального, тупо выражение -> плюсовая конструкция. Может быть удобно для кодогена.

То есть, ты хочешь сказать, что хаскель использовать проще лиспа?

То есть, ты хочешь сказать, что хаскель использовать проще лиспа?

Нет.
Но у них интерпретатор «так себе».

Погулите что-то типа «транслятор прямо s-выражений в C++»

есть какой-то L++, может подойдёт?

https://bitbucket.org/ktg/l/src/master/

Я его десять минут искал по памяти и не нашёл.

Зато нашёл https://github.com/eratosthenesia/lispc вот это.

Ну смените интерпретатор. Интерпретаторы обычно сильно проще чем код на плюсах. У тебя собственно какой интерпретатор?

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

Может Guile подойдёт?

Компилятор под ещё и самопальный сабсет схемы ты не найдёшь, только самому лепить.

Если там совсем дубовое, можно посмотреть на какую-нибудь tinyscheme, для замены интерпретатора.

guile для его задачи подохреваю что жирный слишком будет. Я там выше предлагал уже.

cast Croco и его [url=http://www.intelib.org/]InteLib[/url] — что нового и планируется ли его как-то развивать вообще?

InteLib ?

алсо см. кандидатскую вышеозначенного А. В. Столярова, в публикациях – хотя там похоже автореферат, в полном тексте подробнее: C++98, SFINAE, макросня, S-выражения через С++ шаблоны макроснёю транслируются в объекты с «операцией пробел» (в полном тексте про это подробнее) и «алгебра S-выражений» транслируется в рантайм поддержку «алгебры С++ объектов» с такими вот операциями, поверх которого потом этими объектами делается мини-схемка InteLib как библиотека шаблонов С++.

довольно тривиальный факт, на самом деле. существует «алгебра программ», «система алгоритмических алгебр» – ещё со времен Глушкова, Дейкстры, Цейтина, операторных схем Янова. которая представляет собой если точнее математическую структуру, lattice, решётку. частично упорядоченную, то есть алгебру/моноид с как-то введённым отношением частичного порядка. например, CFG это орграф, вот вам частичный порядок раз. 5 операторов структурного программирования (последовательное выполнение – выражения в моноиде «;», альтернатива/ветвление, цикл_пока, цикл_для, вызов_функции или вычисление_выражения или присваивание) – тоже моноид, тоже частично упорядоченный. вот вам ещё.

и вообще, никлаус вирт сказал, что алгоритм + данные = программа, а ковальски – что алгоритм = логика + управление. то есть. дальше это можно и дальше раскручивать – метапрограммы, метаалгоритмы, металогики, и какие-то ХЗ что для метауправления.

вот вам ещё моноидов.

и вообще. в каком-нибудь хаскеле если расписать такую вот «алгебру выражений» и то как она транслируется – сразу будет достаточно очевидно, что тут моноид моноидом через моноид всю дорогу. одна алгебра (S-выражений), моноид погружается в другую (С++ шаблонов и объектов) и выражает по сути третью (программа=алгоритм+данные= данные+логика+управление и потом к обоим этим частям применяем теоркатегорное уравненение «амальгама в категории», и сразу всё становится предельно ясно чего куда и как).

ещё из занятного: диссер кандидатской К. Книжника про ООБД Goods. С++98, SFINAFE, шаблоны используются для реализации метаобъектного протокола в сервере ОО СУБД, рефлексии по тайпинфо. про совмещение С++ и МОП.

подозреваю, что на каком-нибудь С++20 и концептах с constexpt это было бы глобальнее и надёжнее. но синтаксис совершенно не человеко читаемый.

а на каком-нибудь D с CTFE и рефлексией по тайпинфо – ещё и прочитать это можно.

ещё из хтоничного существует PowerLoom и STELLA презентация . язык который транслируется в С++ и CL. подмножество обеих с синтаксисом на Sexprs. 40 мб исходников, компилируется в нечто большее.

EuLisp:

• EuLisp
• EuScheme
• YouToo
• Eu2C

кластер метапарадигм – Leda читать

вот вам ещё решёток — частично упорядоченных моноидов

Eu2C >> abstract

"""

Eu2C is a EuLisp to C compiler developed as part of the APPLY project at theFraunhofer-Institute for Software Engineering and Systems Engineering. There are two main problems for Lisp users: 1. the efficiency, by which we mean both the runtime efficiency and the efficiency of storage use and 2. the unsatisfactory integration capability of Lisp programs with other programs. Our way of solving these problems is to compile Lisp applications into C. The aims of the Eu2C development were -efficient execution of Lisp applications comparable to that of C-programs and -simple integration of Lisp programs into non-Lisp environments. To implement and describe the runtime system and to achieve high performance of the C-programs generated we must have a language that can handle C-data types and C-values. For this purpose we have developed a typed Lisp-like implementation language called TAIL. You can describe the representation of data, the type schemes and the type lattice with TAIL. Thus we have the possibility to carry out experiments with different data representations or type schemes without changing the Eu2C-compiler. TAIL can also be used as the basis for the implementation of other Lisp dialects. A type inference system has a great effect on the speed of Lisp programs. With a good type inference system you can reduce the number of dynamic type checks and replace calls of generic functions by direct calls of methods. A C-compiler has the best results for optimization of C-programs if the C-programs look like programs written by experienced programmers. We call this kind of C-code «natural C-code». Our approach is, for example, to use the parameter passing mechanism of C instead of using a special Lisp stack to achieve very fast function calls. """

сравни например:

• Leda на lex/yacc
• какой-то минипаскаль, например P4
• azLint

на тему простоты реализации.

вообще, вот например [лисп на прологе](https://www.metalevel.at/lisprolog/] как цепочка метаинтерпретаторов.

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

язык это определённая структура выражений, например, «алгебра S-выражений», «алгебра программ». идея лиспа, пролога, форта – что имидж ничто – жажда всё синтаксис не важен, это самая простая форма которая позволяет невозбранно достигнув желаемого реализовать eval – простейшую модель вычислений.

почему это получается? потому что такие модели composable.

например, S-выражения это моноид. гомоиконный, который единообразно позволяет в формах описать как данные, так и код. это всё элементы выражения. то есть. моноид данных погружён в моноид кода через apply, а моноид кода в моноид данных – через eval. то есть, eval/apply – моноиды высших порядкод.

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

в лиспах это очевидно. в прологах или фортах – не так очевидно. но они тоже гомоиконны, а следовательно – машинописуемы, а не только лишь машиночитаемы.

то есть, метапрограмма. программа, которая пишет программу – пишет просто данные. которые по смыслу код.

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

макросы могут быть и на форте : CREATE..DOES и на прологе – см. тот сайт.

здесь чем проще язык, тем проще код. или метакод. метаинтерпретатора, то есть интерпретатора такого языка на себе самом. который становится расширяемым «на самом себе», словно истинный метапрог

где-то внутри у машины, исполняющей сей язык торчит по сути моноид.

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

или в лиспе вот, со списками.

поверх этого «базового моноида» в машине языка есть другой. и третий. и далее, моноиды высшего порядка.

сохраняющие структуру, упорядоченность type lattice. и прочих математических структур, lattice, решёток. отношений частичного порядка на таких гипермоноидах.

более-менее полноценная реализация «лиспа на прологе» есть в prologmud котрорый logicmoo который есть в стандартных пакетах swi-prolog.

там он используется для поддержки OpenCyc и его онтологий.

то есть, «текстовая адвентюра» однопользовательская расширяется в MUD многопользовательский расширяется в MOO программируемый на языке типа Lua с ООБД, процессами, акторами – на котором можно либо долго и нудно скриптовать всех NPC-ей и логику их поведения как в каких-нибудь обычных MUD-ах (из навороченного: CoffeeMUD на Java с наворотами)

– либо как в прологе выводить из фактов-предикатов Cyc, задающих онтологию факты-правила и знания базы знаний и далее какой-то конкретный код кодогенерировать.

сравни, кстати, форматы представления знаний в CycL , PowerLoom.

какой-то DSL на базе лиспа. для чего для его интерпретации и/или кодогенерации встраивают какой-то простой недолисп.

scryer-prolog на Rust, shentong – реализация лиспа Shen на Хаскеле, abominable-klambda-compiler – ещё одна затычка для генерации из лиспа в хаскель.

потом на таком прологе раскрутить более-менее полноценную реализацию лиспа, типа shen. потом на нём – всё остальное.

logicmoo, prologmud, wam_common_lisp, cyc

обучающее видео как кодит logicmoo

в исходниках logicmoo можно найти недоинтерпретатор лиспа , запросы к cyc онтологиям

занятная дока

и потом к обоим этим частям применяем теоркатегорное уравненение «амальгама в категории», и сразу всё становится предельно ясно чего куда и как

см. амальгаму про кодекартов квадрат (копредел) – про амальгаму в теории категорий и про Амальгаму в универсальной алгебре можно почитать.

также полезно почитать про универсальную алгебру вообще.

рефлексия по тайпинфо

ещё одна lattice, частично упорядоченная.