An import expression has a module name field but a module has no name

[winksaville]

In syntax/modules.rst an import expression must reference a module by name:

import ::= { module name, name name, desc importdesc }

But the syntax for a module has only definitions for various entities such as types, funcs, memory, ... there is no name.

Currently it seems each compiler appears to just assume some module name for entities that are imported. In clang the import statements use env where as the modules used in the wabt wasm-link tests generally use __extern.

It seems to me a module expression should have at least optional name.

[rossberg]

The name of a module is not internal to the module definition but defined by outside context. Very much like the file name of a source file in traditional languages.

[winksaville]

But when something is imported a module name is required, as the author of module A that is going to import something from another module I've got to provide some module name to import from. So it seems I have to decide the actual module name not at compile time, but link time. Thus flexible linkers will need to provide a mapping of the "internal module name" assumed in import expressions to the "external module name" provided at link time, correct?

…

On Mon, May 22, 2017, 11:50 PM rossberg-chromium ***@***.***> wrote: The name of a module is not internal to the module definition but defined by outside context. Very much like the file name of a source file in traditional languages. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#485 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA-hHK27oVQ7RJm7kRY5H63TL2mp7Otfks5r8oG9gaJpZM4NjAX6> .

[rossberg]

On 23 May 2017 at 09:36, Wink Saville ***@***.***> wrote: But when something is imported a module name is required, as the author of module A that is going to import something from another module I've got to provide some module name to import from. So it seems I have to decide the actual module name not at compile time, but link time. Thus flexible linkers will need to provide a mapping of the "internal module name" assumed in import expressions to the "external module name" provided at link time, correct?

Yes. How module names map to physical or logical resources is completely up to the API, the embedder, and client glue code running there. For the JS API, you control it with the arguments given to the `instantiate` function.

[winksaville]

What principle would be violated by allowing an optional name to be assigned at compile time? On Tue, May 23, 2017, 12:43 AM rossberg-chromium <notifications@github.com> wrote:

…

On 23 May 2017 at 09:36, Wink Saville ***@***.***> wrote: > But when something is imported a module name is required, as the author of > module A that is going to import something from another module I've got to > provide some module name to import from. So it seems I have to decide the > actual module name not at compile time, but link time. Thus flexible > linkers will need to provide a mapping of the "internal module name" > assumed in import expressions to the "external module name" provided at > link time, correct? > Yes. How module names map to physical or logical resources is completely up to the API, the embedder, and client glue code running there. For the JS API, you control it with the arguments given to the `instantiate` function. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#485 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA-hHIfBZ2Ocy5dH8LgP705EGhicP-1Oks5r8o4TgaJpZM4NjAX6> .

[rossberg]

It's not clear what that would mean. Take the JS API. The instantiate function just takes a random import object whose properties correspond to the expected module names. There is nothing that connects the objects behind these properties back to specific modules or their would-be names. It's just a bunch of objects. They do not even originate from a Wasm module necessarily. And even if they were and had an internal name, how would that relate to their property name in the import object?

Think of module instances as values. You may bind an instance to a name just like you can bind a numeric value to a variable. But a module does not have a name built in, just like a number hasn't.

[sbc100]

I wonder if "module name" might then be the wrong terminology then? I think this issue came up because "module" is often used to refer to a web assembly module, but "module name" is the import is really more of a namespace, defined by the embedder it seems. Perhaps something more like "namespace" would be less misleading?

[winksaville]

I thinking of the use case where node modules are "linked" after compiling by a "wasm-linker" before instantiating. For instance wasm-link in wabt can be used to merge multiple modules into a single module. Before a PR I created wasm-link assumed all modules were named `__extern`. If an import statements `module name` was something else, such as `env` which is what clang/llc generates as the `module name` wasm-link would fail. The PR is very simple and simply saves the `module name` instead of failing if its not `__extern`, but since modules don't have names the `module name` is currently useless. I could also imagine that a module name would be extremely useful for a dynamic linker, possibly running as a wasm module itself. So is there a downside to a module having a optional name?

…

On Tue, May 23, 2017 at 9:31 AM Sam Clegg ***@***.***> wrote: I wonder if "module name" might then be the wrong terminology then? I think this issue came up because "module" is often used to refer to a web assembly module, but "module name" is the import is really more of a namespace, defined by the embedder it seems. Perhaps something more like "namespace" would be less misleading? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#485 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA-hHDn8C9etUdxlFqn6K9zaFOGPqzKnks5r8wn9gaJpZM4NjAX6> .

[winksaville]

@sbc100, calling it namespace is just fine and possibly clearer. But to be useful we need to create name spaces at "compile" time. So adding a namespace expression and nesting export expressions in them would be perfectly reasonable. But I'd still say its seems reasonable that a module have an optional name, but adding the notion of a namespace and being able to construct them would do the trick.

[jfbastien]

We've referred to namespaces in the design repo before, seems like a logical thing to call this. What @rossberg-chromium says about instantiate taking the import object is spot on, and means that the name isn't inherent to a module or to an instance, but rather to an import object.

I'd also suggest thinking about integration with ES6 modules when it comes to naming.

[winksaville]

So would creating a namespace expression with nested export expressions and then have import expressions reference a namespace. And then this namespace would be the name in the `from` section of an ES6 import statement. Thoughts?

…

On Tue, May 23, 2017 at 4:18 PM JF Bastien ***@***.***> wrote: We've referred to namespaces in the design repo before, seems like a logical thing to call this. What @rossberg-chromium <https://github.com/rossberg-chromium> says about instantiate taking the import object is spot on, and means that the name isn't inherent to a module or to an instance, but rather to an import object. I'd also suggest thinking about integration with ES6 modules when it comes to naming. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#485 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA-hHAeMEBc2hjCufoIp-vpbPl38iRh7ks5r82kqgaJpZM4NjAX6> .

[jfbastien]

So would creating a namespace expression with nested export expressions and
then have import expressions reference a namespace. And then this namespace
would be the name in the from section of an ES6 import statement.

Sorry, I parse error on this. Can you write some pseudo-code?

[rossberg]

On 23 May 2017 at 18:31, Sam Clegg ***@***.***> wrote: I wonder if "module name" might then be the wrong terminology then? I think this issue came up because "module" is often used to refer to a web assembly module, but "module name" is the import is really more of a namespace, defined by the embedder it seems. Perhaps something more like "namespace" would be less misleading?

Well, it's the API-side representation of a "module" that is more general because it includes "host modules" that are not implemented in Wasm. In the future, that will presumably incorporate ES modules as well. So I think the term module is justified, it just doesn't imply "Wasm module".

[winksaville]

@jfbastien, if I had the following source:

$ cat src/addTwo.cpp 
namespace Math {
    int addTwo(int a, int b) {
        return a + b;
    }
}

I was thinking something like the following might be generated:

$ wasm2wast addTwo.wasm
(module
 (namespace "Math"
   (export "addTwo" (func $addTwo))
 )
 (func $addTwo (param $0 i32) (param $1 i32) (result i32)
  (i32.add
   (get_local $1)
   (get_local $0)
  )
 )
)

And then in JS you might have something like:

import * as Math from "addTwo";
console.log(`addTwo(1,2)=${Math.addTwo(1,2)}`);

[jfbastien]

OK so you're specifically thinking about ES6 modules. Right now the only naming is in the import object which is disjoint from the instance being imported as well as its underlying module.

I think this is something we'll want to tackle once we do ES6 module integration, not before. That'll guarantee we get things right.

[rossberg]

I believe we can close this for now, since the original question has been answered. ES6 module integration is a separate topic that's specific to the JS API.