Re: [MirageOS-devel] How to implement protocols?

[David Sheets <sheets@xxxxxxxxxxxx>]

On Sat, Nov 14, 2015 at 6:28 PM, Thomas Gazagnaire
<thomas@xxxxxxxxxxxxxx> wrote:
>>> The whole point is to have multiple instances of the functor in the same 
>>> program. We want the ability to link multiple TCP/IP stacks (instantiated 
>>> with different arguments) to create virtual networks for benchmarks or 
>>> tests.
>>
>> I would just like to remind that functors are not the only way of 
>> structuring programs. Function application is a very versatile glue aswell.
>
> So the alternative you propose is to thread function parameters everywhere. 
> I'm not sure this is much better.
>
> To rephrase the nice slide decks from Pierce and Harper:
>
> Also, on slide 25:
> "path hacks! Much nicer to express linking in a real programming language.
> "Agreed. But functors are not the only possible ânice linking language.â Why 
> not invent a real language with primitives for manipulating linking contexts 
> in the style of search paths?"
>
> Instead to invent a language to manipulate linking context, we use an eDSL 
> and that's Functoria. Functoria manipulates functors, but also opam package 
> and ocamlfind libraries, so you can implement path hacks in there if you want.
>
> slide 26:
> "Functors can arise when a library module needs to refer to a client module 
> (because the library implementor doesnât know what name will be chosen for 
> the client module)."
> "Somewhat, but perhaps one could also address this sort of application with 
> âpath hacksâ or a more sophisticated linking language"
>
> The problem we have in Mirage is not a problem of client name, it is a 
> problem of client implementation. We already have defined all the possible 
> client signatures that an application can use, that's mirage-types. Should we 
> provide a base implementation for every signature defined in mirage-types and 
> ask the users to build against them, then use path hacks to switch from the 
> base implementation to the real implementation at link time? (as a side note, 
> what happens with cmx and cross-module inlining in that case?) That might be 
> possible, if only we had  good build system :p (the myocamlbuild.ml doing 
> that kind of thing is here[1])
>
> slide 27:
> "Functors are needed when we want to implement the same signature multiple 
> times and use more than one of the implementations in the same run of a 
> program."
> actually this appears very often in Mirage, especially when you want to test 
> the various implementations of you signature in the same test program or when 
> you want to superpose various layers of implementations (virtual dispatcher, 
> etc...).
>
> I agree we are over functorizing in some cases (Console and IO are good 
> candidates) but for the network and storage stack, we have concrete exemple 
> where most if the functors are actually needed. I'm happy to experiment with 
> simpler system if it actually exists. Experimenting with path hacks in 
> functoria (or with the next build system) could be a first step in that 
> direction (even if I'm a bit worried to loose some cool possibilities).

I have a recent data point regarding de-functorization:

In <https://github.com/mirage/ocaml-9p/pull/18>, Thomas Leonard
replaced Dave Scott's Log functor argument with Daniel Buenzli's logs
library. This made the logging system a global singleton, as far as I
can tell, which has repercussions (exactly as Thomas Gazagnaire says)
for, e.g., testing as found in
<https://github.com/mirage/ocaml-9p/pull/20> where it was trivial to
instantiate two 9p client stacks with differently behaving loggers (in
this case, simply prefixing the name of the client instance was
sufficient).

There are a number of ways this problem could be solved and I do not
claim that alternative functor invocations are the best way. In
particular, the lack of sharing specification makes abstraction over
the functor argument more difficult with the requirement to use
first-class modules, more functors, or duplicate code. The
functorization approach does make module construction more unwieldy
and a singleton can, in some cases, be 'nicer' to think about. I would
like to point out, though, how *easy* and *obviously correct* it was
to use the functorization to achieve my testing/logging goal.

Ideas welcome,

David

> Best,
> Thomas
> [1]: https://github.com/mirage/mirage/blob/one-build/scripts/myocamlbuild.ml
>
>
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel

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