Introduce arbitrary import/export depth
Closed this issue · 6 comments
Among the things introduced are single-level imports/exports, how about, introducing arbitrary depth imports/exports? Any integer >= 1 that is.
For example, 3-level imports would be useful to maintain the 2-level depth, while using the ESM integration proposal.
(import "./mod.mjs" "Math" "random" (func $Math::random (result f64)))Although, of course, I could re-write the host's code to use a single-level import in that case, but for multiple values that are already inside of an object, this becomes cumbersome.
That's a great point. The PR #26 already generalizes the alias syntax to support a sequence of N exports (link), so probably it makes sense to also allow N exports in import statements as well.
One question is whether we should have N-level imports show up as such in the binary/text format, or have them just be sugar for a single-level import of nested instances + alises. I would think the latter, treating the fixed-2-level-import form as "legacy".
With #35 merged and Module Linking as a new layer embedding core wasm, there are no longer two-level imports in the AST, text or binary format. We could consider re-adding them to the text format as syntactic sugar, in which case the generalization to N-level makes sense, but I wonder, without the requirement of backwards compatibility: is it worth the complexity?
@alexcrichton @rossberg thoughts?
In my experience implementing support for the earlier proposal in Wizer, significant complexity was involved in synthesizing instances / instance types from sequences of 2-level imports. I'd prefer that either we don't add 2-level imports back, or we don't make them implicitly define instances / instance types.
I would personally go for the more conservative route and require single-level imports now that and adapter module is different from a core module. I'd figure we could add sugar/extras in the future if necessary.
Staying conservative for now makes sense to me. The desugaring of multi-level imports is complex and has many nasty corner cases when there are overlaps.
Ok, thanks all for the feedback. I'll close this issue for now and we can reopen or file a new issue in the future if we want to reconsider.