Module dialect

[Roger-luo]

While we primarily focus on kernel functions, most of the time because we are allowed to link a Python Method object we do not need a symbol table and thus we do not need a module. In the cases when we compile to a specific target, e.g QASM2 file, LLVM IR, module become necessary to bundle everything together.

I initiatied a module dialect in #151 to work towards this goal, however there are a few things left to figure out

how Method refer to a Module if the method is defined as a function inside the module

• option A: assume each module has an entry point, then the module can have a CallableOpInterface
• option B: Method.code points to a function-like statement and optionally also points to a module statement
  that contains the function-like statement

how should interpreter load the module symbol table?

I'm thinking to let each dialect group "own" a symbol table that gets updated whenever the dialect group is used as a decorator for a kernel function or used as a code generation target. This way we pass the symbol table around accross multiple interpreters without re-constructing the symbol table.

See also #117

cc: @weinbe58

[weinbe58]

I see, so you can invoke methods that may even have stubs on one system but could execute on another.