From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 BE1B57ED99 for ; Wed, 27 May 2015 22:22:07 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of alain@frisch.fr) identity=pra; client-ip=85.233.204.164; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="alain@frisch.fr"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of alain@frisch.fr) identity=mailfrom; client-ip=85.233.204.164; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="alain@frisch.fr"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mx20.yaziba.net) identity=helo; client-ip=85.233.204.164; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="alain@frisch.fr"; x-sender="postmaster@mx20.yaziba.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ABAwAcJmZVnKTM6VVch2G+SAEGhHyCUwKBQz4OAQEBAQEBAREBAQEBAQgLCQkhLoQjAQEEIxVAEQsOCgICBRYLAgIJAwIBAgFFBgEMCAEBiC2uLaQRAQEIAQEBAR6BIYoZhQyCaIFFAQSeF4d4jzUCgQSDGYM0AQEB X-IPAS-Result: A0ABAwAcJmZVnKTM6VVch2G+SAEGhHyCUwKBQz4OAQEBAQEBAREBAQEBAQgLCQkhLoQjAQEEIxVAEQsOCgICBRYLAgIJAwIBAgFFBgEMCAEBiC2uLaQRAQEIAQEBAR6BIYoZhQyCaIFFAQSeF4d4jzUCgQSDGYM0AQEB X-IronPort-AV: E=Sophos;i="5.13,507,1427752800"; d="scan'208";a="155567719" Received: from mx20.yaziba.net ([85.233.204.164]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 27 May 2015 22:22:07 +0200 Received: from mta20.int.yaziba.net (unknown [10.4.20.31]) by mx20.yaziba.net (mx10.yaziba.net) with ESMTP id CBB2C1A7462; Wed, 27 May 2015 22:22:06 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mta20.int.yaziba.net (Postfix) with ESMTP id E0702149451; Wed, 27 May 2015 22:22:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at mta20.int.yaziba.net Received: from mta20.int.yaziba.net ([127.0.0.1]) by localhost (mta20.int.yaziba.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EboEWCdof0WL; Wed, 27 May 2015 22:22:06 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mta20.int.yaziba.net (Postfix) with ESMTP id BE54914946B; Wed, 27 May 2015 22:22:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at mta20.int.yaziba.net Received: from mta20.int.yaziba.net ([127.0.0.1]) by localhost (mta20.int.yaziba.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id dkdHap0gCCIL; Wed, 27 May 2015 22:22:06 +0200 (CEST) Received: from [192.168.1.14] (APuteaux-655-1-128-71.w92-132.abo.wanadoo.fr [92.132.199.71]) by mta20.int.yaziba.net (Postfix) with ESMTPSA id 84064149451; Wed, 27 May 2015 22:22:06 +0200 (CEST) Message-ID: <5566276E.7040701@frisch.fr> Date: Wed, 27 May 2015 22:22:06 +0200 From: Alain Frisch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Yannis Juglaret , caml-list@inria.fr References: <5565DD11.6080608@giovannangeli.fr> <5565E11B.7010300@giovannangeli.fr> <5565E49B.9090209@gmail.com> In-Reply-To: <5565E49B.9090209@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-DRWEB-SCAN: ok X-VRSPAM-SCORE: -100 X-VRSPAM-STATE: legit X-VRSPAM-CAUSE: gggruggvucftvghtrhhoucdtuddrfeekuddrfeefgdeltdcutefuodetggdotefrucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepkfffhfgfggfvufhfjggtgfesthejrgdttdefjeenucfhrhhomheptehlrghinhcuhfhrihhstghhuceorghlrghinhesfhhrihhstghhrdhfrheq X-VRSPAM-EXTCAUSE: mhhouggvpehsmhhtphhouhht X-Validation-by: alain@frisch.fr Subject: Re: [Caml-list] Matching exhausitvity with GADT and modules On 27/05/2015 17:36, Yannis Juglaret wrote: > This is a question to the list: is there any good reason for allowing > abstract types in module implementations, and not just in module > signatures -- where they can actually be used to abstract types? Abstract types in structures can be used to represent opaque foreign values manipulated through the FFI (typically custom blocks, or blocks which cannot -- or need not -- be described as OCaml types). Alain