From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 842E57EE9C for ; Thu, 1 Dec 2016 12:51:26 +0100 (CET) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=alain.frisch@lexifi.com; spf=None smtp.mailfrom=alain.frisch@lexifi.com; spf=None smtp.helo=postmaster@vrout30.yaziba.net Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of alain.frisch@lexifi.com) identity=pra; client-ip=185.56.204.35; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="alain.frisch@lexifi.com"; x-sender="alain.frisch@lexifi.com"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of alain.frisch@lexifi.com) identity=mailfrom; client-ip=185.56.204.35; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="alain.frisch@lexifi.com"; x-sender="alain.frisch@lexifi.com"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@vrout30.yaziba.net) identity=helo; client-ip=185.56.204.35; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="alain.frisch@lexifi.com"; x-sender="postmaster@vrout30.yaziba.net"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3AcwC7Ghw6iDfzV43XCy+O+j09IxM/srCxBDY+r6Qd?= =?us-ascii?q?2+MeIJqq85mqBkHD//Il1AaPBtSAra4dwLOK+4nbGkU4qa6bt34DdJEeHzQksu?= =?us-ascii?q?4x2zIaPcieFEfgJ+TrZSFpVO5LVVti4m3peRMNQJW2aFLduGC94iAPERvjKwV1?= =?us-ascii?q?Ov71GonPhMiryuy+4ZPebgFGiTanbr5+MRq6oRjeu8ILnYZsN6E9xwfTrHBVYe?= =?us-ascii?q?pW32RoJVySnxb4+Mi9+YNo/jpTtfw86cNOSL32cKskQ7NWCjQmKH0169bwtRbf?= =?us-ascii?q?VwuP52ATXXsQnxFVHgXK9hD6XpP2sivnqupw3TSRMMPqQbwoXzmp8rxmQwH0hi?= =?us-ascii?q?gZKzE58XnXis1ug6JdvBKhvAF0z4rNbI2IKPZyYqbRcNUHTmRDQ8lRTTRMDJ6i?= =?us-ascii?q?YYsBD+QPPuhWoIfyqFQMsRSwChKhBP/txzJSmnP6waM33uYnHArb3AIgBdUOsH?= =?us-ascii?q?HModjpMKcdS+G1zK/VxjvDdfNW2Cz955TIchs8pvyDR7ZwftDQyUkpDQ/FgE+Q?= =?us-ascii?q?qY3+PzyJ1uQAqGyb4PRvVOKuhW4nqht9rSSoxscpk4TEgJ8exFPc9Shh3Yo4Jt?= =?us-ascii?q?21RFR7bNOlCpdcqT2WOoRsTs4sQ2xkoDs2x74GtJKhYiQHxo4ryhrBZ/CdboSF?= =?us-ascii?q?7R3uWeCMKjlinn1lYqiwhxOq/Eig1OL8Us603U5UripfldnMq2wN2hLP5sSdSv?= =?us-ascii?q?py5Eag2TeU2A/J8O1EJ147lbbDJ54gxL4/iIYTvFzeEiL1mEj6lq+be0Q+9uS2?= =?us-ascii?q?9+jqba/qq5GcOoNsjwHxKKUumsixAeQiNQgOWnCW9v641LL5/E35Rq9GjvMskq?= =?us-ascii?q?nYq5DVOcQbq7W9AwBL3Ycj6hi/Dza83NsEmnkHKUpJeAibgIjxJ1HOPPf4AO+j?= =?us-ascii?q?jFu2lTdrw+nKPrngApXWMnjOi6zhfLZ4605E0gU/19Ff55ROCrEAOv3/QEHxtM?= =?us-ascii?q?bAAh88NAy73vjoBc1m1oMbRWKPGqiZML7OsQzA2uV6D+CSZYNdkTL5MP89/7a6?= =?us-ascii?q?gWUw3FkQYrKB2JYLYWukF/9lZU6eZCyoyvsEEHsQr0IUQej7wAmOVD9PfWf0Va?= =?us-ascii?q?849xk0DYunCcHIQYX7xPSq1SK/VrlXfXwOXluFFHOtc4SfR98NbjiTK4lviGpX?= =?us-ascii?q?e6KmTtoI0RivskfU0bt8JeqcriQcvJPlktZv5vbYlTk2+Cx1AcXb2GaIGTIn1l?= =?us-ascii?q?gUTiM7ifgs6Xd2zU2OhO0h26RV?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BsAAABDkBYhyPMOLldHAEBBAEBCgEBF?= =?us-ascii?q?wEBBAEBCgEBgw0BAQEBAYElpSgOklyEE4YiAoJDEAEBAQEBAQEBAQEBEgEBAQo?= =?us-ascii?q?LCQkdMIIzGgGCGwEBBCMEEVELDgoCAiYCAlcGAQwIAQGIbQGrVoFsPYtQAQEIA?= =?us-ascii?q?QEBASOBC4UzgX2CXodNgl0BBJpegXiPGIoLhiuKGINihAoCNYEYRINKgWmKNAE?= =?us-ascii?q?BAQ?= X-IPAS-Result: =?us-ascii?q?A0BsAAABDkBYhyPMOLldHAEBBAEBCgEBFwEBBAEBCgEBgw0?= =?us-ascii?q?BAQEBAYElpSgOklyEE4YiAoJDEAEBAQEBAQEBAQEBEgEBAQoLCQkdMIIzGgGCG?= =?us-ascii?q?wEBBCMEEVELDgoCAiYCAlcGAQwIAQGIbQGrVoFsPYtQAQEIAQEBASOBC4UzgX2?= =?us-ascii?q?CXodNgl0BBJpegXiPGIoLhiuKGINihAoCNYEYRINKgWmKNAEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,282,1477954800"; d="scan'208";a="202458216" Received: from vrout30-bl.yaziba.net (HELO vrout30.yaziba.net) ([185.56.204.35]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Dec 2016 12:51:25 +0100 Received: from mtaout20.int.yaziba.net (mtaout20.int.yaziba.net [10.4.20.37]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by vrout30.yaziba.net (mx10.yaziba.net) with ESMTPS id F2FF152043; Thu, 1 Dec 2016 12:51:24 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mtaout20.int.yaziba.net (Postfix) with ESMTP id E436616055F; Thu, 1 Dec 2016 12:51:24 +0100 (CET) X-Virus-Scanned: amavisd-new at mtaout20.int.yaziba.net Received: from mtaout20.int.yaziba.net ([127.0.0.1]) by localhost (mtaout20.int.yaziba.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id fAgZJt8m0dbt; Thu, 1 Dec 2016 12:51:24 +0100 (CET) Received: from [10.0.210.40] (unknown [185.23.92.144]) by mtaout20.int.yaziba.net (Postfix) with ESMTPSA id C5D911601E7; Thu, 1 Dec 2016 12:51:24 +0100 (CET) To: David Allsopp , Dmitry Bely , Caml List References: From: Alain Frisch Message-ID: <3f89d13a-14f0-090b-be96-d3f67fcb95f3@lexifi.com> Date: Thu, 1 Dec 2016 12:51:25 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: 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: gggruggvucftvghtrhhoucdtuddrfeelfedrgedugddukecutefuodetggdotefrucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepuffvfhfhkffffgggjggtgfesthejredttdefjeenucfhrhhomheptehlrghinhcuhfhrihhstghhuceorghlrghinhdrfhhrihhstghhsehlvgigihhfihdrtghomheqnecukfhppedukeehrddvfedrledvrddugeegnecurfgrrhgrmhepmhhouggvpehsmhhtphhouhht X-VRSPAM-EXTCAUSE: mhhouggvpehsmhhtphhouhht Subject: Re: [Caml-list] GADT memory representation On 01/12/2016 10:52, David Allsopp wrote: > Dmitry Bely wrote: >> I need to access/modify GADT data from C glue code. What is their memory >> representation? Is there any difference from ordinary sum types? > > It's the same - GADTs are "just" add a lot of clever typing stuff on top of a normal sum type - they don't affect the runtime operation of the code. > >> Unfortunately OCaml manual doesn't even mention GADTs in section >> "Interfacing C with OCaml". > > That's worth a GPR/Mantis issue. I'm not sure we want to document the memory layout of GADTs. I don't think there are concrete plans to do so, but it might be considered to change the representation of GADTs so that they cannot be used to compare values of different types with the polymorphic comparison function. Today you can write: type t = E: 'a -> t let () = assert(E 1 = E true) A similar "bad" behavior used to be available for exceptions and this was "fixed" by changing their representation (their "slot" now has object_tag and a (per process) unique id). We might want to do the same for GADTs (not an easy decision since it would add a lot of overhead) and for first-class modules as well. Alain