Создание простого DSL в Haskell с взаимодействием C++

Question

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

Существует большая база кода в C++ с соответствующими моделями и библиотеками ввода-вывода, поэтому этот язык должен быть в состоянии вызывать C++. Тестируемые системы предъявляют жесткие временные требования, поэтому мы не можем допустить большого дрожания в тестовой среде. Нашим прошлым решением был пользовательский DSL, встроенный в среду выполнения C++, но в итоге мы заново изобрели слишком много колес (синтаксический анализатор, линтер, интерактивный интерпретатор и т. Д.), Чтобы получить необходимые статические гарантии.

Возможности Haskell для создания встроенных DSL с этими гарантиями чрезвычайно привлекательны для меня, но я застрял в определении того, как встроить их в мягкую среду выполнения C++ в реальном времени. Есть идеи? Указатели на любые библиотеки / существующие проекты будут с благодарностью!

Answer 1

Похоже, что путь наименьшего сопротивления будет EDSL, который генерирует C++. Таким образом, вам не нужно беспокоиться о возможном несоответствии между программным обеспечением реального времени и GHC RTS.

Вы можете посмотреть, как реализованы другие EDSL, которые генерируют PL:

• HJScript использует бесплатный монадный подход для встраивания JS.
• JMacro использует больше внешнего подхода DSL, но встроен через TH. Не будет моим выбором.

Вместо того, чтобы генерировать строки кода C++, хорошо иметь структуру данных. К сожалению, похоже, что нет пакета, доступного для C++. Тем не менее, вы можете взглянуть на language-c - возможно, расширить его или создать свой собственный. Вы можете даже подумать о создании C и использовании взаимодействия C-C++, предоставляемого этими языками.

Я бы, вероятно, отговорил вас от изучения дизайна Cryptol или Cogent, поскольку это полноценные языки программирования (которые, как вы указали, склонны избегать).