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

[Jon Crowcroft <jon.crowcroft@xxxxxxxxxxxx>]

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 <anil@xxxxxxxxxx> wrote:

> On 13 Nov 2015, at 15:43, Daniel BÃnzli <daniel.buenzli@xxxxxxxxxxxx> 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
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