Rebase this proposal on top of Module Linking

[lukewagner]

In the current explainer, the mechanism by which (@interface func)s and (@interface implement)s link with the core module's imports and exports is rather magical and limited. This linking can be explained and generalized in terms of the concepts introduced by Module Linking. Doing so also makes it much clearer what exactly is imported and exported in the final adapted module: it's the same story for when one module nests another.

This "rebase" also pulls in a ton of discussion and iteration with @fgmccabe and @eqrion about the proposal in general. In particular:

• adapter functions are now a full superset of core functions, allowing arbitrary core wasm control flow and computation, while still preserving the original optimization goals by making interface types affine
• the proposal now gives a full account of strings, lists, records and variants which, combined with the previous generalization, enables a much wider range of representations to be lifted and lowered efficiently w/o serialization
• as a test and demonstration of the new generality of lists, the string type is now just an abbreviation for (list char) (with char being added as a new scalar interface type)

Lastly, use cases and additional requirements are updated to reflect our updated understanding. Happy to get feedback on this new draft!

[mijamo]

I just want to say that I read the full overview in this pull request and I love it. Until now interface types were not super clear to me, I understood the basic idea but not the instructions nor the architecture, in particular with non-string types.

The current explanation is well explained and seems to cover most of the needs I had identified for such a feature. Examples are clear and relevant, so congratulations for such a wonderful job!

For me the part that really made it click was the list lifting explanation and example, this is where I suddenly understood the whole laziness and uniqueness problem, because it relates to traditionnal iterator problems. I think that actually the possibility to use list for iterators is very interesting and could be mentionned more prominently rather than being just a side note.

All in all it just sounds great and I can't wait playing with it!

[taralx]

Rendered version for the lazy like me.

[taralx]

  (adapter_func (export "run")
    call $core.$run
  )

Can this be an exported alias instead?

[lukewagner]

@mijamo Thanks! I added two sentences to call out the iterator use cases a bit more prominently.

@taralx That's right. I added a note to make this a bit more clear.

[zakbaig]

@lukewagner Are we close to a phase 2 stage with this PR?!

[lukewagner]

@zakbaig We're closer, but still several TODOs left, I believe.

[lukewagner]

In the last commit, I merged and rewrote the last two use cases into a single one that I think more clearly states the high-level use case of "maximizing reuse" and how the proposals helps achieve that. Credit to @fgmccabe for the suggestions on how this could be improved.

[lukewagner]

Thanks for the review!