-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Programmatic import resolution #53
Comments
The current design is intentional. I think it is crucial to avoid making the basic interface higher-order, since that would be very inconvenient to map to plain C and even harder (and likely more costly) to access from FFI bindings. The interface you propose can be implemented very easily on top of what's currently provided, but not vice versa. (Also, there are valid use cases where it is simpler to treat imports/exports positionally and not having to care about their names at all, see e.g. the examples. Basically, whenever you are in control of the binary.) |
The problem is that positional correspondence does not provide the embedder enough information to resolve imports at all, except by convention or out-of-band information such as parsing the imports itself. Names, kinds, and signatures are the language of imports, so a complete API needs to expose them. (And about layering, you actually cannot implement named import resolution on top of positional correspondence without out-of-band information, whereas the opposite is easy if the contract is to request imports through the programmatic interface in import order). |
Actually, sorry. Now that I look at it, I guess it is possible to extract the imports from the module itself and then do the lookups programmaticallly. |
Yes, that was the idea. |
In the proposed API, the creating of an instance (
Instance::make()
) takes an array of imports. Presumably, this array positionally corresponds to the imports declared for a module. As such, the declared module and import names within the module would be ignored. I think we should change this API to allow the instantiator to supply an implementation of class that does import resolution, something along the lines of (roughly):class ImportResolver {
const Memory* resolveMemory(const char* module_name, const char* import_name);
const Func* resolveFunc(const char* module_name, const char* import_name);
. . .
}
The text was updated successfully, but these errors were encountered: