Should we allow inline export syntax for modules and instances?

[Pyrolistical]

As its not possible to define func in adapter modules, it it illegal to write (func (export "exp")). However since we are allowed to define modules and instances, the inline export syntax would make sense. But should we allow it?

Allowed

(adapter module
  (module $M
    (func)
  )
  (export "exp" (module $M))
)

(adapter module
  (module $M)
  (instance $i
    (instantiate $M)
  )
  (export "exp" (instance $i))
)

Should we allow?

(adapter module
  (module $M (export "exp")
    (func)
  )
)

(adapter module
  (module $M)
  (instance $i (export "exp")
    (instantiate $M)
  )
)

I vote no, as it this breaks the design constraint of not requiring special processing of core modules and this would break that. And simply for consistency, we don't allow this for instances either, as it would be the strange odd one out.

[lukewagner]

(Sorry for the slow reply; I was OoO for the week)

That's a great question and good point w.r.t not changing the core text format of (module ...).

So, while the current module-linking proposal has no way to define (and thus inline-export) functions, interface-types adds (canonical adapter) func definitions where it would make sense to allow export sugar. So then it starts to make sense to have all adapter-module definitions support inline export sugar other than module.

But actually, if we're willing to walk the line a bit, the way this inline export sugar is defined in the Text Format spec is via this convention of ahead-of-parsing rewrite rules (e.g.). Thus, we could define the analogous (module (export <name>) ...) ≡ ... abbreviation in the adapter-module layer, which gets rewritten into a vanilla (module $M ...) parsed by the core Text Format followed by an (export <name> (module $M)). Then it could all be uniform without cheating too much.

[Pyrolistical]

That makes sense. Especially since the binary format isn't affected and that's the main way core modules are going to be consumed. The text format is going to get more confusing, but that's OK. It was never meant to be a primary means program wasm. As long as its unambiguous we're OK.