can anyone point me at a decent dissection of the merits of generics v. functors and why C++ templates were such a fiasco?
On Fri, Nov 13, 2015 at 4:37 PM, Anil Madhavapeddy <[email protected]> wrote: > > > On 13 Nov 2015, at 15:43, 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. > > One of the design goals of Cohttp was to allow multiple, completely > independent network stacks (including sockets and direct stacks) to run > within the same program. It has also been fairly successful at getting > third parties to port the appropriate part of the interface that they need > to different backends, such as Andy Ray doing a JavaScript version that > uses only the higher-level parts of the stack. > > It's also worth noting that you can even use Cohttp_async and Cohttp_lwt > within the same program, as Jeremie Diminio did an Lwt-on-Async adapter. > This isn't necessarily advisable, but it is possible :-) Again, this will > all be consolidated when we have a more standard concurrency story within > OCaml, but functorising IO wasn't an entirely terrible decision. > > Where functors fall over is the terrible documentation and tooling > assistance when faced with using one, and this is being addressed by codoc > and Merlin. > > > Other than that the document feels like unstructured, poorly written > [1], random rumblings. > > Grumpy day, eh? I thought it was an excellent first cut that laid out > some of the issues to consider for beginners wishing to build their own > protocol. We can iterate on it, which is Hannes' intention for sending it > to this list. > > -anil > _______________________________________________ > 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
