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 7C69B7EE63
	for <caml-list@sympa.inria.fr>; Mon, 13 May 2013 11:40:28 +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.15.3;
  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.15.3;
  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.15.3;
  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: AtkBALi0kFHU4w8Dm2dsb2JhbABavjuGKxYOAQEBAQEGCwsJFCiCYHs0BSiILQEWnCCWBR+IYI9Fgl5hA5crhgSOQw
X-IPAS-Result: AtkBALi0kFHU4w8Dm2dsb2JhbABavjuGKxYOAQEBAQEGCwsJFCiCYHs0BSiILQEWnCCWBR+IYI9Fgl5hA5crhgSOQw
X-IronPort-AV: E=Sophos;i="4.87,660,1363129200"; 
   d="scan'208";a="17109922"
Received: from mout.web.de ([212.227.15.3])
  by mail2-smtp-roc.national.inria.fr with ESMTP; 13 May 2013 11:40:16 +0200
Received: from frosties.localnet ([95.208.119.3]) by smtp.web.de (mrweb001)
 with ESMTPSA (Nemesis) id 0LyE7R-1UPsPN0kLd-015ao9 for <caml-list@inria.fr>;
 Mon, 13 May 2013 11:40:16 +0200
Received: from mrvn by frosties.localnet with local (Exim 4.80)
	(envelope-from <goswin-v-b@web.de>)
	id 1UbpEt-0002SQ-MH
	for caml-list@inria.fr; Mon, 13 May 2013 11:40:15 +0200
Date: Mon, 13 May 2013 11:40:15 +0200
From: Goswin von Brederlow <goswin-v-b@web.de>
To: caml-list@inria.fr
Message-ID: <20130513094015.GB8366@frosties>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Provags-ID: V02:K0:kkB2yEKbNqDCIkxbpxaEodAgslvRekX3TInkoQtzaOu
 U+jKwB2LVlGAeAnNdVMA+a60OZmgyZ1DFyqYeEQj8960wNnbDm
 lDLhPEugRjZmWRJHRs9B/X9hPJDBNkX7sbzZa9zRa3/w2laAUE
 hdpZIlLawq7PVHJfD/munkYVkUz+L6Tim99BP9v364a0f/vLoQ
 +jpuYBZgvixZMKCHbGkqQ==
Subject: [Caml-list] RFH: type / consistency problem

Hi,

I have two C types like this:

   struct Request {
     uint32_t cmd_type;
     uint32_t size;
     uint8_t  data[];
   };

   struct Reply {
     uint32_t reply_type;
     uint32_t cmd_type; // the cmd_type of the request this reply is for
     uint32_t size;
     uint8_t  data[];
   };

Note: The C types are given and they do not have a request ID or
anything that can be matched to a reply, only the cmd_type. 2 requests
with the same cmd_type must not happen concurrently.

Now in the ocaml bindings this becomes maybe:

   type request = Foo of string | Bar of int | Baz
   type cmd_type = Foo | Bar | Baz
   type msg = Error of string | Buzz of float | Burr
   type reply = { cmd_type : cmd_type; msg : msg; }

Or should I rather keep track of request on the C side, match replies
to requests and use requests in the reply type like this?

   type reply = { req : request; msg : msg; }

On top of that there is a connection between request and reply
contents. A Foo request can get an Error or Buzz while Bar/Baz can get
Error or Burr. Anything else would be invalid. It would be nice if the
type system would prevent creating a Burr reply to a Foo request.


So here is my request for your ideas:

How do I match requests to replies with that? How do I ensure that
request and cmd_type remain in-sync over time when new variants get
added? I'm wondering if there is some magic that could be used to
ensure correct types? Maybe something with GADTs? Something that would
bind requests and replies together in some way to ensure corectness.
Other tricks?

MfG
	Goswin