From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <goswin-v-b@web.de>
X-Original-To: caml-list@sympa.inria.fr
Delivered-To: caml-list@sympa.inria.fr
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83])
	by sympa.inria.fr (Postfix) with ESMTPS id 06B7B7EE51
	for <caml-list@sympa.inria.fr>; Mon, 13 May 2013 15:09:21 +0200 (CEST)
Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  goswin-v-b@web.de) identity=pra; client-ip=212.227.17.11;
  receiver=mail2-smtp-roc.national.inria.fr;
  envelope-from="goswin-v-b@web.de";
  x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible
Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  goswin-v-b@web.de) identity=mailfrom;
  client-ip=212.227.17.11;
  receiver=mail2-smtp-roc.national.inria.fr;
  envelope-from="goswin-v-b@web.de";
  x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible
Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  postmaster@mout.web.de) identity=helo;
  client-ip=212.227.17.11;
  receiver=mail2-smtp-roc.national.inria.fr;
  envelope-from="goswin-v-b@web.de";
  x-sender="postmaster@mout.web.de";
  x-conformance=sidf_compatible
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtkBAC7lkFHU4xELm2dsb2JhbABavj6FKYEDFg4BAQEBAQYLCwkUKIIfAQEFJxNPCxgJJQ8FKIgtARayZx+IJI8vFoM/A5crhgSOQw
X-IPAS-Result: AtkBAC7lkFHU4xELm2dsb2JhbABavj6FKYEDFg4BAQEBAQYLCwkUKIIfAQEFJxNPCxgJJQ8FKIgtARayZx+IJI8vFoM/A5crhgSOQw
X-IronPort-AV: E=Sophos;i="4.87,662,1363129200"; 
   d="scan'208";a="17154473"
Received: from mout.web.de ([212.227.17.11])
  by mail2-smtp-roc.national.inria.fr with ESMTP; 13 May 2013 15:09:13 +0200
Received: from frosties.localnet ([95.208.119.3]) by smtp.web.de (mrweb002)
 with ESMTPSA (Nemesis) id 0LfiZ8-1U9gXa1HdC-00pewm for <caml-list@inria.fr>;
 Mon, 13 May 2013 15:09:12 +0200
Received: from mrvn by frosties.localnet with local (Exim 4.80)
	(envelope-from <goswin-v-b@web.de>)
	id 1UbsV5-0003Aj-SC
	for caml-list@inria.fr; Mon, 13 May 2013 15:09:11 +0200
Date: Mon, 13 May 2013 15:09:11 +0200
From: Goswin von Brederlow <goswin-v-b@web.de>
To: caml-list@inria.fr
Message-ID: <20130513130911.GJ8366@frosties>
References: <20130513094015.GB8366@frosties>
 <m49vc6nqduu.fsf@coffee.modeemi.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <m49vc6nqduu.fsf@coffee.modeemi.fi>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Provags-ID: V02:K0:E+Xl2YSAX97ilEHd5zTyIW176FtyLiTbXds/3yBkRB0
 L3mb2f3C0fWPaJa/yrTMVzoXi2O2MP/DgS6PLtWa6hZEWyqtau
 kUwxvpi7OkQjz5kINUwm6tvcQNB3rHOoCKoYXLoGfdM+Jyzf61
 4fiLvpzd1AV45efL3SoSVQliZzP0guqRtAn7tPPJkPLbExQLG8
 XdkzqEodGv8KXtQSgrGeQ==
Subject: Re: [Caml-list] RFH: type / consistency problem

On Mon, May 13, 2013 at 03:11:05PM +0300, Erkki Seppala wrote:
> Something like this?
> 
> module Protocol : sig
>   type 'a request
>   type 'a reply
>   type session
> 
>   val issue : session -> 'a request -> 'a
> 
>   type foo_response = { fr_s : string }
>   val foo : string -> foo_response request
> 
>   type bar_response = int
>   val bar : int -> bar request
> 
>   type baz_response = unit
>   val baz : unit -> baz request
> end = struct
>   type 'a reply = string -> 'a
>   type 'a request = {
>     req_type : int;
>     req_data : string;
>     req_handle : 'a reply
>   }
> 
>   type foo_response = { fr_s : string }
>   
>   let issue session request =
>     send (request.req_type, request.req_data);
>     request.req_handle (receive ())
> 
>   let foo int = 
>     let handle_foo_response str =
>       { fr_s = str }
>     in
>       { req_type = 42; req_data = Printf.sprintf "hello %d" int;
>         req_handle = handle_foo_response }
> 
>   (* etc *)
> end
> 
> The nice thing about this is that you can support synchronous and
> asynchronous communication with essentially the same interface of
> constructing messages, you just have a different kind of issue function.

There is no connection between the 'a of a request, req_type and the
req_data. req_data isn't even the raw data anymore but, I assume,
already the serialized data ready for sending. So you have gone from 2
independet types to 3. I could create a foo_responce request with
req_type = Bar containing the data for type Buzz.

And what about the server? It reads requests from the network and has
to send out matching replies. I'm actually more interested in that
side, but both should work and have the same common type.

MfG
	Goswin