FascinatedBox / lily

Interpreted language focused on expressiveness and type safety.

Home Page:http://lily-lang.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Dynaload should use a load table instead of a loading function

FascinatedBox opened this issue · comments

Dynaload is a mechanism in Lily for loading different elements of a package only when they're really necessary. It's a very old mechanism that's been through a number of revisions. Back when it was first introduced, there was no api for pushing values. It was necessary to have a loader function since vars would need to return a value, whereas functions return themselves.

Since 1.0, there is an api. Var loaders push a value onto the stack but don't need to return anything. Functions still return themselves.

Functions are implemented as follows: void lily_...(lily_state *s). Now that vars have an api and don't need to return a value on the heap, they have the same void lily_...(lily_state *s) signature.

What I'm proposing is a breaking change to dynaload. Instead of binding generation creating a loader function, it creates an array of entries. Those entries are either vars, NULL, or functions.

This will involve some adjusting in the core, which means that this will be a breaking change. I've done some work on packaging, but I'll hold off on that until this is done. I suspect people will be pulling the latest Lily, and I want the packaging to start off with the lowest versions already having this change done. Otherwise they'll be immediately obsolete.

If you're writing a Lily library, all you'll need to do once this is done is to grab the latest bindgen and re-run it on the library in question.