Does adapter module support kind first import sugar?

[Pyrolistical]

The explainer uses this example to show the new alias kind first form,

(func $f (import "i" "f")) ≡ (import "i" "f" (func $f))  ;; (existing)
(func $g (alias $i "g1"))  ≡ (alias $i "g1" (func $g))   ;; (new)

In the same example, it also shows the two existing import forms. While these two import forms are supported in core modules, it creates uncertainty if these forms also are supported in adapter module import definitions.

Most of the kinds would work naturally for both forms, however we run into a problem when importing a module.

(adapter module
  ;; Just fine
  (func (import "imp 1"))
  (memory (import "imp 2") 1)
  (global (import "imp 3") (mut i32))
  (table (import "imp 4") 1 funcref)

  ;; Danger! Looks like a instance definition but isn't.
  (instance (import "imp 5")
    (export "exp" (func))
  )
  ;; Import first form is more clear
  ;; (import "imp 5" (instance
  ;;   (export "exp" (func))
  ;; ))

  ;; Danger! Looks like a core module but isn't.
  (module (import "imp 6")
    (import "imp func" (func))
    (export "exp func" (func))
  )
  ;; Import first form is more clear
  ;; (import "imp 6" (module
  ;;   (import "imp func" (func))
  ;;   (export "exp func" (func))
  ;; ))
)

Do we want to support kind first forms?

If so, are we OK with the module import confusingly looking like a core module? We can fix the core module confusion by requiring module imports to be (adapter module (import "imp 6")) (but this still isn't great as its confusing a nested adapter module) or just disallow kind first form for module imports.

We could also only allow kind first forms only for core definitions. Meaning kind first forms are disallowed for instance/module imports. But this seems arbitrary.

[Pyrolistical]

This also applies to alias actually. Is (instance $x (alias $y "exported instance")) and (module $a (alias $b "exported module")) supported?

[lukewagner]

Good question! On first consideration, I'm ambivalent. @rossberg WDYT?

[rossberg]

Hm, I seem to remember that we discussed this before.

I agree that that the distinction becomes a bit subtle, at least for examples like these. But is it actually ambiguous? If the import clause closes right after the name, then it cannot be an import declaration itself. I believe this is even LALR(1)?

[Pyrolistical]

Its not ambiguous, but can be confusing to the reader. I'm happy to go either way. I'm just trying to pin this down for the polyfill. The answer of "we haven't decided yet" is acceptable as well.

[Pyrolistical]

I went ahead and implemented all the inline forms in the polyfill, even the confusing looking module one.
You can check it out in the demo https://concept-not-found.github.io/module-linking-polyfill/

[lukewagner]

Thanks!