Rename miden to miden_lib

[hackaugusto]

Having a folder called just miden is not descriptive of what it does.

[hackaugusto]

It is also confusing that we have two kernel libraries. It is hard to understand what is going in there. One suggestion is to isolate the user facing procedures, from the internal implementation, a way of splitting it is to have:

• rename the public facing API to just API.
• rename miden to lib as mentioned above

---

Edit: I think I understood what is going on.

The miden contains all the lib code, including the code that is user facing, and code that implements the kernel. And the kernels contains only exposed kernel interface.

Can't we move the kernel implementation inside the kernels folder? And make the miden into a public api only?

[bobbinth]

We need 3 things here:

1. Kernel API - a MASM library module which is used to define which procedures can be syscall-ed by a program (this file).
2. The "main" procedure for the transaction kernel - i.e., the procedure which is executed when we want to execute the transaction kernel (this file).
3. Public API which developers can call in their smart contracts (e.g., account code and note scripts) - these procedures are located in the miden library (e.g., under miden::account).

All 3 depend on some common procedures which are currently located under miden::kernels::tx. What we could do is move the contents of miden::kernels into a separate library (e.g., kernels library) and then import this library similar to how we do it for stdlib.

This shouldn't be too difficult and I think the nice benefit of this would be that anything under miden::kernels wouldn't be exposed publicly via the miden library. But also, I think we should wait to do this until the assembler/mast refactoring that @bitwalker is working on is done as the outcome of that work may affect the details of how we'd implement this.

[bitwalker]

I'll have my assembler refactoring pushed for review tonight at some point, even if there are some small things left to address, the review can start and that will allow this discussion to proceed with a clear picture of what those changes are.

[bitwalker]

@bobbinth My assembler changes enable quite a bit of additional flexibility now, but one thing that I maintained as an invariant is that kernel modules can't import other modules. There isn't any actual real reason why we need to maintain that as an invariant, rather we just need to ensure that the kernel doesn't call any procedures which transitively depend on itself, which the new module graph can be used to enforce.

So in short, we can definitely introduce that as a new analysis pass for kernel modules, and then loosen the current requirement that kernel modules are "self-contained", just a matter of making that happen once 0xPolygonMiden/miden-vm#1277 is merged.

[bobbinth]

invariant is that kernel modules can't import other modules

I am not sure this is accurate: kernel modules can import modules from libraries. For example, our transaction kernel does import a bunch of procedures from miden-lib.

[bitwalker]

@bobbinth Ah interesting, I mean, that's not an issue, but something that will need to be tweaked in my PR. I think I had been under the impression that kernels had to be self-contained (akin to an OS kernel), but relaxing that constraint is easy to do with the module graph structure my refactoring introduced. Ultimately we just need to guarantee that code in the kernel does not call or syscall other procedures, but as long as that is upheld, pulling in code from other modules doesn't need to be restricted I suppose.

[bobbinth]

Ultimately we just need to guarantee that code in the kernel does not call or syscall other procedures, but as long as that is upheld, pulling in code from other modules doesn't need to be restricted I suppose.

Yes, exactly. Previously, this was difficult to enforce because the assembler did "lazy" parsing/compiling of imported modules, but I think with your current structure we can enforce this properly.

One thing to note: dyncall instruction would fall into the same category as call and syscall.

[bobbinth]

Closing this as after #826, we separated the kernel and user-facing code.