Mu, LibMu and LibMuXxx: Layered API for the client

[wks]

As we discussed today, the structure of Mu and its client-facing interfaces should be like this picture:

(Black text represents the component, and red text represents the programming language they are implemented in.)

In the inner circle is the micro VM. It can be implemented in any language, but it provides a C API, and both the micro VM and the C API (i.e. the inner black circle boundary) need to be verified. Outside the outer circle is the client. The ring in between is a library which we call "LibMu". In theory, the client, the LibMu and the Mu micro VM can be implemented in different languages.

When LibMu (or some language-specific LibMu wrappers, such as LibMu-Z for some hypothetical language Z, as shown in the picture as the client-facing semi-circle) talks with the client, it should present a nice client-friendly interface for the client to construct Mu IR bundles. Such interface should provide appropriate data structures, data types and constructors or even high-level transformers for the convenience of the client. This layer does not need to be minimal.

When LibMu talks with the Mu micro VM, the interface must be minimal and verifiable. We agreed (#50) that it is difficult to verify a parser, so it rules out "sending text or binary blobs into the micro VM (across the black circle)". The C API of the micro VM provides a function call-style API (also discussed in #50, but need to be revised) so that LibMu constructs a bundle into Mu by making a sequence of function calls, each function constructs a Mu IR node (such as instruction, basic block, type or constant).

Some programming languages (such as Python, Haskell, ...) may have relatively high overhead when calling C foreign functions, comparing to direct C-to-C calls. If the client is written in such languages (language Y in the picture), it will be slow to construct the Mu-side AST by frequently calling through the C interface. We consider this as a problem of the language implementation of Y. In such case, the client should have some part of it written in C (the inner micro VM-facing semi-circle in LibMu) so that language Y can encode the MuIR bundle and send it to the C component (this interface does not need to be verified) and the C component constructs the MuIR in Mu via the C API (this interface is verified).