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

[Mark Florisson <mbf24@xxxxxxxxx>]

On 20 November 2014 14:01, Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx> wrote:
>>> foo-type: the definition of the mirage FOO signature
>>> foo: the functors for FOO. Depend on foo-type as we want to check 
>>> signature/implementation matching at compile time. Depends on bar-type, 
>>> baz-type, etc...
>>> foo-unix: the implementation of FOO for unix. Depends on foo.
>>> foo-xen: the implementation of FOO for xen. Depends on foo.
>>> foo-mirage: the implementation of the combinators for foo-type. Depends on 
>>> foo-type. Might add a dependency on a specific versions of foo-unix and 
>>> foo-xen if the right combinators are used when used in a config.ml. For 
>>> each new versions of foo-unix and foo-xen, we need to upgrade the 
>>> constraints (which might be painful) to ensure backward-compatibility. Or 
>>> we can have open constraints, and do a minor release with the right updated 
>>> constraints before bumping the major version number.
>>
>> Can't these simply be subpackages ? Basically the root package foo is 
>> foo-type. All other are subpackages (foo.func, foo.unix, foo.xen, 
>> foo.mirage) whose existence is conditioned by depopts.
>
> That's not so simple unfortunately. You might have x-unix and y-unix which 
> both satisfy the signature in foo-type. An example: a lot of implementation 
> satisfy the KV_RO (key/value store, read-only) signature: ocaml-crunch, 
> mirage-fs-unix. mirage-fat, etc.. In that case, it doesn't really make sense 
> to have all of them in the same package.
>
> Also, from a dependency point-of-view, I think it's clearer to separate the 
> `*-type` packages. All the `*-type` only depends on other `*-type`. The 
> libraries are pure cmis, defining base signatures. They only depend on other 
> `*-type`. The `X` packages define functors over the base signatures. They 
> only depends on other `*-type` modules. I think that quite useful to see that 
> at the dependency level, and not clumsy it with some random depots.
>
>>> $ mirage configure [--xen]
>>>
>>> will install either foo-unix or foo-xen automatically, depending on having 
>>> [--xen] or not on the command-line (as the mirage tool does currently).
>> I think it would be interesting to look if this can be split up a bit with a 
>> kind of mirage-get that handles the installation and then use assemblage's 
>> new rich configuration system for setting up the build system. If we 
>> eventually get to a good default driver (or at least the driver I have been 
>> dreaming about, see assemblage's #145), you would then have the ability to 
>> live with both the xen and unix build side-by-side without having to restart 
>> from scratch each time you switch target.
>
> Agreed this could be neat. Currently the mirage tool also does some other 
> side-effects at configure time:
> - it reads config.ml, look for the different base combinators used
> - install the corresponding opam package
> - generate the corresponding main.ml to use the selected implementations in 
> the right order
> - eventually generate some other .ml files (crunch, fat, ...)
>
> In the future, some of the things could be done by assemblage -- for instance 
> we could provide a Mirage lib for assemblage, to expose the mirage combinator 
> in your assemble.ml. But well, that's a quite far future :p
>
> Thomas
>

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).

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.

If you're interested we can discuss this more in person, I may have a
small draft paper available within a few days.

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