Can imported func be used directly in instantiate?

[Pyrolistical]

I am confused if this is a valid adapter module.

(adapter module (;0;)
  (module (;1;)
    (import "mimp" "f" (func (;0;)))
  )
  (import "f" (func (;0;)))
  (instance (;0;) (instantiate (;module;) 1
    (import "mimp" (func 0))
  ))
)

I believe it is invalid as although the top level imported func happens to have an import name of f, there is still a mis-match as func 0 in (import "mimp" (func 0)) refers to a func not a func with a name.

From my understanding, the correct way to do this is to wrap the imported func in an instance like so:

(adapter module (;0;)
  (module (;1;)
    (import "mimp" "f" (func (;0;)))
  )
  (import "f" (func (;0;)))
  (instance (;0;)
    (export "f" (func 0))
  )
  (instance (;1;) (instantiate (;module;) 1
    (import "mimp" (instance 0))
  ))
)

Is my understanding correct?

If so, I believe the confusion is caused by the fact that (import "mimp" (func 0)) is only allowed in the context of instantiate of a imported module, as imported modules have single level imports. For example, this would be valid:

(adapter module (;0;)
  (import "imp" (module (;1;)
    (import "mimp" (func))
  ))
  (import "f" (func (;0;)))
  (instance (;0;) (instantiate (;module;) 1
    (import "mimp" (func 0))
  ))
)

If my understanding is correct, I think this is going to trip up a lot of people as the grammar seems to allow something nonsensical. Not sure if we can fix this asides from just more documentation and examples.

[lukewagner]

Hi! Good question and your understanding is correct.

So, iiuc, the thing you're saying is confusing is that as a definition, module refers to a core module (which have 2-level imports) whereas a type, module refers to either a core or adapter module, fixing a single-level import (and retroactive way to reframe core modules as having single-level imports). I think that's a great point and it echoes a general concern @rossberg has also raised about having a single (module) type describing both kinds of modules. The alternative we've been discussing (which I think your concern here supports) is having separate core and adapter module types, with the former having two-level imports and the latter having single-level imports. I couldn't think of a compelling reason before to have two separate types, but I think this is one.

---

On a separate, technical note, in the above examples, it appears from the comments that they're considering an outer module as being the first element of its contained module index space (such that the first local module definition starts at module-index 1 instead of 0). The intention in the current proposal is that an outer module is not part of its own module index space (since this allows various kinds of cycles that break everything).

[Pyrolistical]

Thanks for clarifying the module index space. I got confused between the alias skip indexing and thought that applied to module indexing

[lukewagner]

Just as a follow-up on this: component-model/#6 gives core modules and components distinct types (module and component, resp).