Создание простого DSL в Haskell с взаимодействием C ++
Я разрабатываю простой интерпретируемый язык для тестирования встроенных систем реального времени. Поток управления строго ограничен, чтобы обеспечить сильные статические гарантии того, что будут делать сценарии + как долго они будут работать. Например, вы можете только переходить на постоянные условные выражения или циклически выполнять фиксированные диапазоны.
В C ++ существует большая кодовая база с соответствующими моделями и библиотеками ввода-вывода, поэтому этот язык должен иметь возможность обращаться к C ++. Тестируемые системы предъявляют жесткие временные требования, поэтому мы не можем допустить большого дрожания в тестовой среде. Нашим прошлым решением был пользовательский DSL, встроенный в среду выполнения C ++, но в итоге мы заново изобрели слишком много колес (синтаксический анализатор, линтер, интерактивный интерпретатор и т. Д.) Для достижения необходимых статических гарантий.
Возможности Haskell для создания встроенных DSL с этими гарантиями чрезвычайно привлекательны для меня, но Я застрял в определении того, как встроить его в мягкую среду выполнения C ++ в реальном времени. Есть идеи? Указатели на любые библиотеки / существующие проекты будут с благодарностью!
Решение
Похоже, что путь наименьшего сопротивления будет EDSL, который генерирует C ++. Таким образом, вам не нужно беспокоиться о возможном несоответствии между программным обеспечением реального времени и GHC RTS.
Вы можете посмотреть, как реализованы другие EDSL, которые генерируют PL:
- HJScript использует свободный монадный подход для встраивания JS.
- JMacro использует больше внешнего подхода DSL, но встроен через TH. Не будет моим выбором.
Вместо того, чтобы генерировать строки кода C ++, хорошо иметь структуру данных. К сожалению, похоже, что нет пакета, доступного для C ++. Тем не менее, вы могли бы взглянуть на язык с — возможно, расширить это или построить свой собственный. Вы можете даже подумать о создании C и использовании взаимодействия C-C ++, предоставляемого этими языками.
Я, вероятно, отговорил бы вас от рассмотрения дизайна Cryptol или Cogent, поскольку это полноценные языки программирования (которые, как вы указали, склонны избегать).
Другие решения
Других решений пока нет …