|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [MirageOS-devel] mirage-entropy
>> ...So we ended up simplifying the build system (no needs for complex build >> rules anymore) but putting back the complexity in the functor language. And >> functors slowly started to contaminate our code base 'cause now, every >> library using a functor should also expose a functor. > > to check: the "contamination" you refer to is simply the (moderate) extra > syntactic complexity of making the developer have to deal with functors, or > are there other implications? This also means that when you are developing a new library which use an already functorised library, that new library also needs to be functorized over (at least) the same signatures. So if you are very far in the functor chain, the number of parametrised signature you should depend on might grow quite large. See [1] for instance ... but at least you fully track the dependencies and it is easier to switch, inside the langage instead of passing flags to the linker (as B. Pierce explained nicely in the slides that Daniel sent). [1] https://github.com/mirage/mirage-tcpip/blob/master/lib/tcpip_stack_direct.mli#L24 >> To tackle the difficulty of using functors, we had two strategies. The first >> one was to develop, during last december, an EDSL to describe the >> composition of functors[3], which was what we finally released in mirage >> 1.0. The second one was to be a bit more structured about how we design new >> libraries. We continue to use the linking trick for modules where there is >> clearly no way to have two concurrent implementation running at the same >> time in the same module. In the same time, we try to provide to the user, >> when possible, default functor instantiation in separate ocamlfind package >> to make easier to use the libraries. So most of the mirage >> libraries[4,5,...] are structured as follows: >> - a core ocamlfind package, which consumes and provides a functor, which is >> independent of the backend >> - a .lwt (should be called .unix really) ocamlfind subpackage, which applies >> the functors to work with Lwt_unix functions >> - a .xen ocamlfind subpackage, which applies the functors to work with >> mirage/xen > > how does this fly with functorising across Lwt vs Async as done with cohttp > iirc? would that just mean that the .unix subpackage would have an extra > module parameter supplying one or the other? I should have written .lwt_unix (instead of .unix). Yup, in cohttp we have a an other .async sub-package which instantiate the core functor with Async. The downside of that approach is the number of sub-packages might grow exponentially if we really want to have all of them -- so having partially instantiated functors for lwt-unix/async/xen makes usually is enough. >> Hope it helps clarifying things a little bit, > > yes actually :) this would make a useful blog post i think... (and perhaps > content for a full-monty journal paper about mirage.) I really need to write the Irmin blog post first but yea, why not ... Thomas > > > -- > Cheers, > > R. > > > > _______________________________________________ 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 |