This is a big problem in the language now. There's no solid apis for working with the frontend (invoking the parser and getting a result). The backend apis are acceptable, except that it's difficult to move values around.
I'm a couple of weeks away from the end of a three month release window, so I've (for the moment) given up on trying to finish the apis. But I'm not far from having them done. A month, maybe?
But after that, I'll write a guide on how to embed Lily, and how to extend it.
For the moment, your best bet if you're creating a standalone package like postgres is to refer to how postgres structures the dynaload table. If you're looking to embed the interpreter, it's awkward and hard.
Once this release cycle ends (July 10, Lily's true 5 year anniversary), it's the first thing on my list. I want to give people a solid api so that other people can start building stuff and not have to worry about me breaking it.
First the api, then the tooling, then documentation. You've got my word on that (and HN won't let me delete this, on top of that).
I'm a couple of weeks away from the end of a three month release window, so I've (for the moment) given up on trying to finish the apis. But I'm not far from having them done. A month, maybe?
But after that, I'll write a guide on how to embed Lily, and how to extend it.
For the moment, your best bet if you're creating a standalone package like postgres is to refer to how postgres structures the dynaload table. If you're looking to embed the interpreter, it's awkward and hard.
Once this release cycle ends (July 10, Lily's true 5 year anniversary), it's the first thing on my list. I want to give people a solid api so that other people can start building stuff and not have to worry about me breaking it.
First the api, then the tooling, then documentation. You've got my word on that (and HN won't let me delete this, on top of that).