Skip to content
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

Closed
titzer opened this issue Nov 21, 2018 · 4 comments
Closed

Programmatic import resolution #53

titzer opened this issue Nov 21, 2018 · 4 comments

Comments

@titzer
Copy link

titzer commented Nov 21, 2018

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);
. . .
}

@rossberg
Copy link
Member

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.)

@titzer
Copy link
Author

titzer commented Nov 30, 2018

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).

@titzer
Copy link
Author

titzer commented Nov 30, 2018

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.

@titzer titzer closed this as completed Nov 30, 2018
@rossberg
Copy link
Member

Yes, that was the idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants