From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p1LIgpTq020420 for ; Mon, 21 Feb 2011 19:42:51 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkJAIpAYk1iilswZWdsb2JhbACEH5NYjlENCQoIEgMhqk08ghyEX4kJAQQEAYEig0F2BIUNikE X-IronPort-AV: E=Sophos;i="4.62,201,1297033200"; d="scan'208";a="91756997" Received: from nm13-vm0.bullet.mail.ne1.yahoo.com ([98.138.91.48]) by mail2-smtp-roc.national.inria.fr with SMTP; 21 Feb 2011 19:42:45 +0100 Received: from [98.138.90.55] by nm13.bullet.mail.ne1.yahoo.com with NNFMP; 21 Feb 2011 18:42:44 -0000 Received: from [98.138.87.11] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 21 Feb 2011 18:42:44 -0000 Received: from [127.0.0.1] by omp1011.mail.ne1.yahoo.com with NNFMP; 21 Feb 2011 18:42:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 937743.93126.bm@omp1011.mail.ne1.yahoo.com Received: (qmail 53993 invoked by uid 60001); 21 Feb 2011 18:42:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1298313763; bh=qXrxNbs6dHmzWZXWihh5XEvCEuMTRAkg5A+8sFH7Sf4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=SUOfexbAz0V4Wd6IuQrh0mHnogaiW4XbC/pDrvGAnU01T4OLGMPLpxaFHBiWIGDQ4N6l7oGCYZX+UWeTHycuafuJn4YlXDjjAjQTP8Uuy3f4bj70ZIySnXFLRwaJEQfNkIrNH1app3MxO3BWDHCAK8Yt1g8Sh97jTHfF7+WdVpk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=mRdxPtpmeju40FxjuPuRcwX6Ta0lBbYRCt1c7ZhleC1H5LsQI+lSSoW6eOPi6f5ES0zTh4JGTsSTwr+knRz7u1uDYgZz/9POUWT/LKBnMhvxlv4QlWp74rP3YpWsfc+B4ScfypkJ91y+rYYjOenpE9BbIoTz5rKxlBgeFa1qOmE=; Message-ID: <982043.53335.qm@web111502.mail.gq1.yahoo.com> X-YMail-OSG: 3VuyB74VM1nYRHmO14wgB2qOsK_OIdFV7BBPWhwX1zD1_0R awZAeaRc0INZLYUOJHQVxhWVBawxq4N7d6ImaFaXaW42hoXsST_muWmaqLD4 G039pP_gX6lm26NzNM.MDwj7zKXdOSv_XK6fE4XRq0rzQXG_3uj_2Pp9hnWh Ue7BPZKaCij11zDYCwxKSlBI6FYUd42B14fWP5hB6fs1oIVtHEU1xt_8zIJR 2mZ4w2K.GVdPoKYRRK_Y8ER2dEbSGBhoF1u5_HdX4yp_nfV.5U713DAsXJPq PajLLemBFrubhu_PLcGhHHOGOiIykMRDG83gnyGTyL0gtIi55.xkG2KwPcwD jBmTCLAY1Cbc98DKdX5DIt9H7Rp6_sGmkYOKEAZt.MbOz6_WtnJ7INtfLCZg tuu7CtUQifpcS Received: from [213.205.70.206] by web111502.mail.gq1.yahoo.com via HTTP; Mon, 21 Feb 2011 10:42:43 PST X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.109.292656 Date: Mon, 21 Feb 2011 10:42:43 -0800 (PST) From: Dario Teixeira To: Guillaume Yziquel Cc: caml-list@inria.fr In-Reply-To: <20110221170702.GJ25151@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id p1LIgpTq020420 Subject: Re: [Caml-list] Constraining abstract type to be of a given subtype Hi, > But I think that you will not be able to do such type narrowing in a > module interface / module interface fashion. At least not without an > indication of covariance or contravariance. And even then, I'm not sure > if that is possible. Perhaps I am indeed pushing the module language beyond its design intentions, but my requirement does not strike me as completely unreasonable... If I get rid of the constraint altogether, then I lose the guarantee that kind_t is a subtype of Kind.t. But if I declare kind_t = Kind.t in the signature FOO, then I lose the ability to declare particular instances of FOO to be more *tightly* constrained than the generic Kind.t. Any further ideas on how I may be able to have my cake and eat it too? Cheers, Dario Teixeira