What’s your experience like so far with this?

[chrisdone]

I assume you’ve been using this for a project, @paf31. What’s your experience been like so far? Trade offs? What was good, bad, or surprising?

I am still interested in exploring it for scripting. Just limited in time.

[paf31]

Hi Chris!

So far, the experience has been good. I have been trying it out with some low priority ideas I've had, and it's generally been satisfying to use.

The biggest downside I've noticed is a lack of generality - everything currently operates effectively in a ReaderT r IO, which is mostly fine, but excludes some obvious use cases like non-determinism or continuations, without some tricks which might not be semantically what you want. The original version worked with any monad, but you needed MonadFix for recursion, which would also have excluded some useful monads. Even a fully general monadic interpreter is less interesting than something like HOAS or CCCs, where there are even more interesting examples that we could compile to, e.g. automatic differentiation or incremental computations. And really, those are the examples that make the idea most compelling - anything you can do with a IO-based interpreter could probably be done just as easily with a service integration rather than an embedded DSL (with the possible exception of some things you can do with Haskell's IO that are more difficult in other languages, such as lazy IO or parallel evaluation). I'd like to see if there's any good way to get that level of generality without complicating the API too much. I imagine the simplest approach would be to have a handful of different interpreters in different styles, and not aim to have them be interoperable in any way.

Also, performance - obviously, I've done nothing to optimize this yet, and there's a lot of low hanging fruit. I should first work on adding a benchmark suite (along with more tests). The back-and-forth between Haskell and interpreted PureScript in the core libraries, especially in type-class heavy code, can incur a large performance penalty, and I'm not sure if it'd be easy to improve that. The most obvious solution is to expose more functions as FFI primitives, without the level of polymorphism that the current standard libraries provide.

[chrisdone]

Thanks for the summary, it gives me a good indication of your priorities.

One wacky idea that’s springs to mind is when Edward Kmett compiled his DSL out to a JIT’d language (or bytecode) and then wrote an interpreter in the DSL for the DSL which was automatically optimized by the JIT. (https://m.youtube.com/watch?v=25RmUl88jSw) While we’re mentioning fun ways to interpret a language, that is.

[chrisdone]

Thanks for the summary, it gives me a good indication of your priorities.

One wacky idea that’s springs to mind is when Edward Kmett compiled his DSL out to a JIT’d language (or bytecode) and then wrote an interpreter in the DSL for the DSL which was automatically optimized by the JIT. (https://m.youtube.com/watch?v=25RmUl88jSw) While we’re mentioning fun ways to interpret a language, that is.

Actually on looking at it again, it’s not how I remember it. He’s using Truffle.