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

[Jon Crowcroft <Jon.Crowcroft@xxxxxxxxxxxx>]

ah yes - thanks - so in the Xorp project[1] they made heavy use of
templates (for aforesaid performance reasons) and got in to deep water
(according to one of my ex PhD students who worked on it, and others
who tried using/extending it)...so that makes sense...on the other
hand, the functor overhead might have been too much too...

1 don't know what current state is - doesn't look immensely alive any
more
 http://www.xorp.org/

> 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