From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <yallop@gmail.com>
X-Original-To: caml-list@sympa.inria.fr
Delivered-To: caml-list@sympa.inria.fr
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104])
	by sympa.inria.fr (Postfix) with ESMTPS id 1D87C7ED25
	for <caml-list@sympa.inria.fr>; Thu, 11 Jul 2013 16:28:41 +0200 (CEST)
Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender
  authenticity information available from domain of
  yallop@gmail.com) identity=pra; client-ip=74.125.82.177;
  receiver=mail3-smtp-sop.national.inria.fr;
  envelope-from="yallop@gmail.com";
  x-sender="yallop@gmail.com"; x-conformance=sidf_compatible
Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of
  yallop@gmail.com designates 74.125.82.177 as permitted
  sender) identity=mailfrom; client-ip=74.125.82.177;
  receiver=mail3-smtp-sop.national.inria.fr;
  envelope-from="yallop@gmail.com";
  x-sender="yallop@gmail.com"; x-conformance=sidf_compatible;
  x-record-type="v=spf1"
Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender
  authenticity information available from domain of
  postmaster@mail-we0-f177.google.com) identity=helo;
  client-ip=74.125.82.177;
  receiver=mail3-smtp-sop.national.inria.fr;
  envelope-from="yallop@gmail.com";
  x-sender="postmaster@mail-we0-f177.google.com";
  x-conformance=sidf_compatible
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AswBAJid3lFKfVKxjWdsb2JhbABahAiDBr5KfggWDgEBAQEHCwsJEgYkgiMBAQQBIx0BGx0BAwELBgULDQICJgICIgERAQUBHAYTh3wBAwkGmgOLf0+Cf4RIChknDRVDh3MBBQyBGo47B4JWgR8Dl1qPZRYphDg7
X-IPAS-Result: AswBAJid3lFKfVKxjWdsb2JhbABahAiDBr5KfggWDgEBAQEHCwsJEgYkgiMBAQQBIx0BGx0BAwELBgULDQICJgICIgERAQUBHAYTh3wBAwkGmgOLf0+Cf4RIChknDRVDh3MBBQyBGo47B4JWgR8Dl1qPZRYphDg7
X-IronPort-AV: E=Sophos;i="4.87,1043,1363129200"; 
   d="scan'208";a="20882592"
Received: from mail-we0-f177.google.com ([74.125.82.177])
  by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 11 Jul 2013 16:28:40 +0200
Received: by mail-we0-f177.google.com with SMTP id m19so6798185wev.8
        for <caml-list@inria.fr>; Thu, 11 Jul 2013 07:28:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        bh=2qN3vHlT/nMuhdeFj/fn0UJY8FEhPJqHUGlvP3mQf3g=;
        b=DqO/NsfC1OGwM252ntGFbBvb1dNgDTrculZ59ph4Kyibp/AetgknBlNx7n/lOSjnr6
         svy9ZuPDy5tqwf7AYEZi73mtlhL61B+41da8FvklETz7OXsIVvsmxiEv/DAscCnp2BbH
         GC6QlWlHbRW+9H//UW0s5r40vY1jUdFkqxjfLm89LVLbCpKga24qVQQ98E8N3ZxavJNs
         6a/Ll3+ZaY+qn7u7WXlDURYmzlBU2kgXe8DdasUlS8mMtCAJmLAzASbBvIVtusqBgplm
         kJbc7LJt1pR2KHlZhdvBHuQJ/m0doayaOhqQ6twbR95kKgC/xfWiPl60HxgUvy0jeWEy
         Xshw==
MIME-Version: 1.0
X-Received: by 10.181.12.10 with SMTP id em10mr20208605wid.14.1373552920487;
 Thu, 11 Jul 2013 07:28:40 -0700 (PDT)
Received: by 10.217.110.200 with HTTP; Thu, 11 Jul 2013 07:28:40 -0700 (PDT)
In-Reply-To: <20130711141735.GC26521@frosties>
References: <20130709204312.GA30194@frosties>
	<CAAxsn=Hgo-jM9XCONt3+8qm80hFYddaKQ0uXFc7pUj-Gc3f+Lg@mail.gmail.com>
	<20130711141735.GC26521@frosties>
Date: Thu, 11 Jul 2013 15:28:40 +0100
Message-ID: <CAAxsn=GFfbspEc0DzecMXs_9ozKM=uiNUtef94EuX1PgCRVypA@mail.gmail.com>
From: Jeremy Yallop <yallop@gmail.com>
To: Caml List <caml-list@inria.fr>
Cc: Goswin von Brederlow <goswin-v-b@web.de>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [Caml-list] GADTs and associative container

On 11 July 2013 15:17, Goswin von Brederlow <goswin-v-b@web.de> wrote:
> Can't GADT using functions be passed as arguments without stuffing
> them into a class object?

Yes.  There are several ways to do so.  The code in the thread that
Alain mentioned uses what is probably the best approach in this case.

> This boxing and unboxing feels wrong. It's wastefull because you
> create dummy objects for the Pair. The key part is a repetition of
> what is already the key in the table. Only the value is actualy
> new information.
[...]
> So I still wonder if one couldn't build a (better) associative
> container from scratch that supports GADTs to describe the type
> dependency between the key and the value without that custom unpack
> function. How much of the above is just there to make it work with the
> standard polymorphic Hahstbl.t?

These issues are also discussed in the thread that Alain mentioned.