Re: [MirageOS-devel] [ANN] IPv6 on Mirage!

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 20 Nov 2014, at 14:47, Mark Florisson <mbf24@xxxxxxxxx> wrote:

> This is very cool, so the idea is to have implementation
> modules/packages declare that they implement a certain interface which
> is provided as a separate package, and to have clients link to these
> implementations either through functors or by explicitly resolving a
> package ('cohttp<0.12')?
> 
> The system you're proposing sounds like it is trying to provide
> "strong modularity", where implementations depend only on interfaces,
> and not on other implementations. There has been recent work on
> Backpack in Haskell which is trying to provide this with the help of
> basically a package DSL, where dependencies may remain 'abstract' to
> be satisfied by some other package (in ML you'd use functors for
> this).

Right, except we're not proposing this system -- it's already how
Mirage works.  A unikernel is parameterised as a functor across Mirage
module types (see the examples in https://github.com/mirage/mirage-skeleton).

The question is how to break up the module types such that we can
assemble them independently of each other as we upgrade the system.

> 
> I'm currently working on a module system in the trend of ML, that is
> attempting to provide strong modularity for both packages and modules.
> The main idea is to regard an interface as a specification that is
> independent of any implementation (that either requires or implements
> the functionality). Evolution of these interfaces can then be
> specified explicitly, through a nominal subtype relation between the
> different versions of the interface. Essentially, you can explicitly
> declare that a newer version of an interface is backwards compatible
> with an older one.
> 
> Dependency resolution now only looks at interfaces, leaving versioning
> with the job of pinning specific implementations and excluding buggy
> ones. The nominal relation allows you to distinguish between semantic
> changes, as opposed to more superficial structures changes.
> 
> Concretely, it uses separate signature packages as you mentioned, e.g.
> cohttp-types. You then have two ways of linking stuff: functors and
> imports. Functors work like
> 
>    functor MyFunctor (set : SetSig) ...
> 
> where SetSig refers to a signature package (in your configuration, you
> might say SetSig=0.1). To then resolve concrete dependencies you do
> 
>    import HashSet as (set : SetSig, eq : Eq)
> 
> grabbing some version of HashSet that is compatible with the
> interfaces SetSig and Eq. Both these constructs are a form of dynamic
> linking. The first allows any compatible version of any
> implementation, the second allows any version of a specific
> implementation. This can be further constrained with versions in
> configuration.

I was nodding along until I saw the "dynamic linking" :-)  The import
that you are proposing is a combination of functor application and some
selection of the implementation (in OCaml, this could be done via
OPAM for example).

The mirage frontend tool currently generates a main.ml that does the
functor application, so you could frame it as a program stage rather than
dynamic linking...

-anil


_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel