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

[Jeremy Yallop <jeremy.yallop@xxxxxxxxxxxx>]

There's a reasonable overview of what's wrong with C++ templates in
the early sections of:

   Specifying C++ Concepts
   Gabriel Dos Reis Bjarne Stroustrup
   POPL 2006
   http://www.stroustrup.com/popl06.pdf

The proposed solution in that paper also has a few similarities with functors.

A high-level (and perhaps slightly biased) summary of the respective
merits:  C++ templates are expanded at the use site and then the
result of expansion is type-checked; with functors, definitions are
type-checked separately from uses.  Consequently, functors can be
given meaningful types, and error messages are as good as for
functions: "the functor F expected an argument of type X, but the
actual argument M has type Y", rather than "expanding these six levels
of templates resulted in a type mismatch somewhere".  C++ templates
have some advantages in terms of performance (e.g. ways of
specializing for particular argument types) which would be harder to
add to a system with types.

On 16 November 2015 at 08:59, Jon Crowcroft <jon.crowcroft@xxxxxxxxxxxx> wrote:
> 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
>

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel