Show HN: liblgpp – an extensible stack based VM for interpreters in C++ | Hacker News Reader

Show HN: liblgpp – an extensible stack based VM for interpreters in C++

github.com

12 pointscodr78 comments

Haven’t ran it yet, but the thinking behind this is sound. Hats off to OP.

“Custom interpreters are powerful and flexible tools that allow solving thorny problems with grace.

The general idea is that distilling the fundamental building blocks in library form makes it possible to reduce needed effort to the point where more problems start to look like custom languages, and where it's affordable to try out new ideas and throw some away.”

- from the repo README

This looks pretty awesome and well-written! I'm surprised it should be slower than CPython. Are all objects reference types in this language like in Python? What kinds of bottlenecks are there currently?

I suspect much of the speed difference is due to choosing a slower dispatch method.

All objects except threads so far are value types, including coroutines, and I plan to push that angle further since I'm a huge fan.

But nothing is stopping you from adding a custom type that stores shared_ptr:s or whatever.

Ahh cool! I hope it takes off :) it looks pretty great.

Looks really interesting. What do you plan to use this for?

Application scripting languages, configuration languages, database query languages, and so on. Lowering the threshold to embedding a custom language has interesting consequences for the choices you make from my experience.

Would you use this for compiling database queries on the fly? I worked on a query engine once, written in Scala and Java, where we’d generate Java from a query and then compile and load the bytecode into a single flat function. I wonder how that would compare with your solution. I suppose it could even be called quite nicely from Java. This thing was working on memory mapped data after all (using sun.misc.Unsafe). The idea was to avoid the indirection caused by lambdas for the separate query operations.

I would like to, but finding the optimal set of foundational building blocks is sort of an ongoing adventure, some of the needed pieces would probably be generally useful enough to fit in the core while you would need to add custom operations and types that are specific to your language.

Some would object to even calling this bytecode, as I'm using structs for operations. But serializing code down the level the VM operates on still has value, and adding encoding/decoding of operations is definitely possible.

Reply on news.ycombinator.com