1

I'm designing a simple interpreted language for testing real-time embedded systems. The control flow is severely restricted to provide strong static guarantees on what the scripts will do + how long they will run. For example, you can only branch on constant conditionals or loop over fixed ranges.

There is a large existing codebase in C++ with relevant models and IO libs, so this language must be able to call into C++. The systems under test have hard timing requirements, so we can't tolerate much jitter in the test framework. Our past solution was a custom DSL embedded in the C++ runtime, but we ended up re-inventing too many wheels (parser, linter, interactive interpreter, etc..) to achieve the static guarantees we need.

Haskell's facilities for crafting embedded DSLs with these guarantees are extremely appealing to me, but I'm stuck in determining how to embed it into the soft real-time C++ runtime. Any ideas? Pointers to any libraries / existing projects would be greatly appreciated!

Don Shoveri
  • 11
  • 2
  • 1
    You can [embed the GHC RTS](https://downloads.haskell.org/~ghc/7.10-latest/docs/html/users_guide/ffi-ghc.html)—in brief, you’d start the runtime with `hs_init()`, and either use [hint](https://hackage.haskell.org/package/hint) to load & run Haskell sources from Haskell, or load a shared library of precompiled Haskell code from C++. (The latter is what they do with [Haxl](https://github.com/facebook/Haxl) code at Facebook.) – Jon Purdy Sep 08 '16 at 21:24

1 Answers1

2

Sounds like the path of least resistance would be an EDSL that generates C++. This way, you don't have to worry about the potential mismatch between soft real-time and the GHC RTS.

You might look at how other EDSLs that generate PLs are implemented:

  • HJScript uses a free monad approach to embedding JS.
  • JMacro uses more of an external DSL approach but embedded via TH. Wouldn't be my choice.

Instead of generating strings of C++ code, it's nice to have a data structure. Unfortunately, there doesn't seem to be a package available for C++. However, you could take a look at language-c — perhaps extend that or build your own. You might even consider generating C and using the C to C++ interop provided by those languages.

I'd probably dissuade you from looking at the design of Cryptol or Cogent as these are fully-fledged programming languages (that you have indicated you are inclined to steer away from).

Steven Shaw
  • 6,063
  • 3
  • 33
  • 44