[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [MirageOS-devel] How to implement protocols?
>> 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). 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |