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 A66DE7EE9C for ; Thu, 1 Dec 2016 16:21:20 +0100 (CET) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=josh@berdine.net; spf=Pass smtp.mailfrom=josh@berdine.net; spf=None smtp.helo=postmaster@out5-smtp.messagingengine.com Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of josh@berdine.net) identity=pra; client-ip=66.111.4.29; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="josh@berdine.net"; x-sender="josh@berdine.net"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of josh@berdine.net designates 66.111.4.29 as permitted sender) identity=mailfrom; client-ip=66.111.4.29; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="josh@berdine.net"; x-sender="josh@berdine.net"; 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@out5-smtp.messagingengine.com) identity=helo; client-ip=66.111.4.29; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="josh@berdine.net"; x-sender="postmaster@out5-smtp.messagingengine.com"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3AHbk5phAzpZCvrPsfnjgSUyQJP3N1i/DPJgcQr6Af?= =?us-ascii?q?oPdwSPv9r8bcNUDSrc9gkEXOFd2CrakV0KyK6uu7CCQp2tWoiDg6aptCVhsI24?= =?us-ascii?q?09vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6nK94iQPFRrhKAF7?= =?us-ascii?q?Ovr6GpLIj8Swyuu+54Dfbx9GiTe5b75+Nhq7oRjeusQYhYZpN7o8xAbOrnZUYe?= =?us-ascii?q?pd2HlmJUiUnxby58ew+IBs/iFNsP8/9MBOTLv3cb0gQbNXEDopPWY15Nb2tRbY?= =?us-ascii?q?VguA+mEcUmQNnRVWBQXO8Qz3UY3wsiv+sep9xTWaMMjrRr06RTiu86FmQwLzhS?= =?us-ascii?q?wZKzA27n3Yis1ojKJavh2hoQB/w5XJa42RLfZyY7/Rcc8fSWdHQ81fVTFOApmk?= =?us-ascii?q?YoUPEeQPIORXr4fzqVUNohSxGRKhBP/zxjJSmnP6wbE23/gnHArb3AIgBdUOsH?= =?us-ascii?q?HModvxM6cSSuC1x7TVwDrddfNZxDb96I7WfRs8pvyMX7VwcdHRyUQ0DAzKkE+Q?= =?us-ascii?q?ppHkPzOTyOsBqW6b4PR8Ve+2jWMstgJ/oiC3y8oti4TFnJ8Zxk3Z+Sljz4s5P8?= =?us-ascii?q?O0RUpjbdK5FJZdszuWO5VqTs8/WW1luSc3xqcItJO9YSME0o4oxwTFZPyCa4WI?= =?us-ascii?q?4gzsVOKWITpgg3JlZa6/ihar/Ui7z+38StG03ExPriVbidnMrWoC1xPS6siBRf?= =?us-ascii?q?ty4EGh2TmO1wDV9O5IO1w7la3eK5I5w74wkIQcsVjbEyL3mUj6lrKaelg59uSy?= =?us-ascii?q?5OnreKvqq5uEO49xkA7+M6AumsKlAeQ/NwgDR2qb+eOn1L3j5kD2W6tFjucrna?= =?us-ascii?q?nYtpDVO94XpqinDA9Jyooj8QqwDy+60NQEmnkKNE5KdwiCj4jtIl3OJPH4Deyj?= =?us-ascii?q?g1m3izdqx/XGPqX7DZnXL3jDlq3hfbdn5EJGxgoz14MX25UBIbgEJLrXW1Tt/I?= =?us-ascii?q?jTBxo9dgi12PrPCdNn14pYV3jZUYGDN6aHk1iT5qoFLvOAZYkY8GL/LOMlz/Tj?= =?us-ascii?q?l3M4n1Jbe6S1i8hEIEukF+hrdh3KKUHnhc0MRCJT5lIz?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BmAABEP0BYhx0Eb0JdHAEBBAEBCgEBF?= =?us-ascii?q?wEBBAEBCgEBgw0BAQEBAYF9pFCSaoIOggWGIgKCCEESAQEBAQEBAQEBAQESAQE?= =?us-ascii?q?BCA0JCR0wgjMaAYIbAQEEJxk6DwsYCSUPARwrBokArR49gxOIPQEKAQEBGwiLG?= =?us-ascii?q?YoqmmORd4kUhjuNeoQMJQaBIhMOI4NKgWhyiUMBAQE?= X-IPAS-Result: =?us-ascii?q?A0BmAABEP0BYhx0Eb0JdHAEBBAEBCgEBFwEBBAEBCgEBgw0?= =?us-ascii?q?BAQEBAYF9pFCSaoIOggWGIgKCCEESAQEBAQEBAQEBAQESAQEBCA0JCR0wgjMaA?= =?us-ascii?q?YIbAQEEJxk6DwsYCSUPARwrBokArR49gxOIPQEKAQEBGwiLGYoqmmORd4kUhju?= =?us-ascii?q?NeoQMJQaBIhMOI4NKgWhyiUMBAQE?= X-IronPort-AV: E=Sophos;i="5.33,282,1477954800"; d="scan'208";a="202492781" Received: from out5-smtp.messagingengine.com ([66.111.4.29]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Dec 2016 16:21:19 +0100 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 5D46A207AD; Thu, 1 Dec 2016 10:21:18 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 01 Dec 2016 10:21:18 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=berdine.net; h= content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=1BjflMRSkgFlqOFFEQ8O8TiZObc=; b=tNDjX5 Q/z5wUyP9x6tbh1X57UwYZ0hdKs4pwTLBoNp+SRJ4O/MzM2VNVbafluPuWOmaynt QpCoA+tcwhZDcIr3tuwf8C3cxUZUsz245nbndljkjmrsxGiIxdK+HxkRgXrZPCL9 AnvluxabOmu1eX05boOoFjf0Q9vBHeM5/fs2U= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=smtpout; bh=1BjflMRSkgFlqO FFEQ8O8TiZObc=; b=esQbdsk72NC+nkb448zMusqP3jgEjI4tx2q43fDIORI/w5 esUlsJHSijZ3FaEQW/WpuDGA9Yo2rJot6/MsCNYPzNGmf2a1oRcI628qZcVWyWjM o3qNrt5lec0UREiCxtWomjgVE8E5tUf72k0R6+wW74pQ/uSyASiPAJd2pqIew= X-ME-Sender: X-Sasl-enc: 9wOlplRIm/O5WUHIBdUpOKQY4CjMD19SwkxbEHXW4iiQ 1480605678 Received: from jjb-mbp.localdomain (unknown [199.201.66.3]) by mail.messagingengine.com (Postfix) with ESMTPA id 03A39249CC for ; Thu, 1 Dec 2016 10:21:18 -0500 (EST) Received: by jjb-mbp.localdomain (Postfix, from userid 994052071) id 1066A78DEB5C; Thu, 1 Dec 2016 15:21:15 +0000 (GMT) From: Josh Berdine To: Caml List In-Reply-To: <3f89d13a-14f0-090b-be96-d3f67fcb95f3@lexifi.com> References: <3f89d13a-14f0-090b-be96-d3f67fcb95f3@lexifi.com> Date: Thu, 01 Dec 2016 15:21:15 +0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Caml-list] GADT memory representation On Thu, Dec 01 2016, Alain Frisch wrote: > 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. FWIW, I would rather polymorphic comparison were removed than GADT's made heavier.