> See http://www.cis.upenn.edu/~bcpierce/papers/modules-icfp.ps for more on this.
The alternative it provides is sharing-by-specification. This requires your implementations to pick a concrete instance of the module you're abstracting over (for instance in slide 42, the implementation of B has "A:AI = A"). I guess the point is you can swap out the concrete A that has been selected, but is there a practical way to do that in OCaml? AFAICT this would require a link-time hack. Also, this approach pollutes all of your signatures, so I don't immediately see it as a win, but I'd be curious to see some real world examples. Are there any OCaml projects using this approach? FWIW, my feeling is that the Cohttp code is hard to read not because of the functorization, but the lack of it. A deliberate choice was made to make the Lwt and Async versions non-uniform to support the differing styles of those two libraries. If it was fully functorized, there would be a single signature and single implementation that could be more easily followed. On Fri, Nov 13, 2015 at 10:43 AM, Daniel Bünzli <[email protected] > wrote: > Le vendredi, 13 novembre 2015 à 15:22, Hannes Mehnert a écrit : > > I personally find the cohttp and TCP/IP code hard to read due to the use > > of lots of functors / module abstractions, which are not necessarily > > needed IMHO. > > Not only they are not needed, it's also the wrong way of handling this as > it is well known that factoring out module dependencies as functors doesn't > scale in practice. The question to ask yourself for using a functor is: do > I need multiple instances of the functor in *the same program* — good > examples: {Map,Set}.Make. > > See http://www.cis.upenn.edu/~bcpierce/papers/modules-icfp.ps for more on > this. > > Best, > > Daniel > > > > _______________________________________________ > MirageOS-devel mailing list > [email protected] > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >
_______________________________________________ MirageOS-devel mailing list [email protected] http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
