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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id DDC587EE51 for ; Tue, 30 Apr 2013 09:56:06 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of garrigue@math.nagoya-u.ac.jp) identity=pra; client-ip=133.6.130.5; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="garrigue@math.nagoya-u.ac.jp"; x-sender="garrigue@math.nagoya-u.ac.jp"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of garrigue@math.nagoya-u.ac.jp) identity=mailfrom; client-ip=133.6.130.5; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="garrigue@math.nagoya-u.ac.jp"; x-sender="garrigue@math.nagoya-u.ac.jp"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mailhost.math.nagoya-u.ac.jp) identity=helo; client-ip=133.6.130.5; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="garrigue@math.nagoya-u.ac.jp"; x-sender="postmaster@mailhost.math.nagoya-u.ac.jp"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAJp4f1GFBoIFdGdsb2JhbABSwhSBGA4BDBUIPIIfAQEEAUMBNQIDCws0ElcGExuHdQWtGoMygRIChguHNQeNYgZ/MweCbmGJE44OlEqBWwkX X-IPAS-Result: AgMFAJp4f1GFBoIFdGdsb2JhbABSwhSBGA4BDBUIPIIfAQEEAUMBNQIDCws0ElcGExuHdQWtGoMygRIChguHNQeNYgZ/MweCbmGJE44OlEqBWwkX X-IronPort-AV: E=Sophos;i="4.87,580,1363129200"; d="scan'208";a="15447767" Received: from rabbit.math.nagoya-u.ac.jp (HELO mailhost.math.nagoya-u.ac.jp) ([133.6.130.5]) by mail2-smtp-roc.national.inria.fr with ESMTP; 30 Apr 2013 09:56:04 +0200 Received: from mailhost.math.nagoya-u.ac.jp (localhost [127.0.0.1]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTP id 3831F6383; Tue, 30 Apr 2013 16:56:02 +0900 (JST) Received: from mailhost.math.nagoya-u.ac.jp (localhost [127.0.0.1]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTP id 0DE2C394C; Tue, 30 Apr 2013 16:56:02 +0900 (JST) DomainKey-Signature: h=Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=; c=nofws; d=math.nagoya-u.ac.jp; q=; s=alpha Received: from tet.garrigue.jp (58x158x128x157.ap58.ftth.ucom.ne.jp [58.158.128.157]) by mailhost.math.nagoya-u.ac.jp (Postfix) with ESMTPSA id AE9E5250C; Tue, 30 Apr 2013 16:56:01 +0900 (JST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jacques Garrigue In-Reply-To: <517F6BB9.4070703@frisch.fr> Date: Tue, 30 Apr 2013 16:56:00 +0900 Cc: OCaML List Mailing Content-Transfer-Encoding: quoted-printable Message-Id: References: <00C57DF0-C6F0-4EDE-8607-2155F3A17146@math.nagoya-u.ac.jp> <517E2818.5040506@frisch.fr> <1EA5B7CE-C0C3-4113-9F8F-C4C3BC888D49@math.nagoya-u.ac.jp> <517F6BB9.4070703@frisch.fr> To: Alain Frisch X-Mailer: Apple Mail (2.1503) Subject: Re: [Caml-list] Request for feedback: A problem with injectivity and GADTs On 2013/04/30, at 15:59, Alain Frisch wrote: > It's reassuring to see that the conservative solution (not assuming injec= tivity of user defined abstract types) does not seem too bad for now, even = if not very satisfying. >=20 > I'm only concerned with: >=20 >> 3) The problem I describe in my first mail. I.e. when defining a type, >> if you use type variables appearing in constrained type parameters, >> you need the type constructors leading to the type variables to be >> injective. This is PR#5985, and it is only fixed in branches/non-vanis= hing. >=20 > Do you think that fixing this unsoundness (without injectivity annotation= s) would lead to reject existing programs? Potentially yes. But I don't know how it is in practice for code existing now. Hence my question. I have now committed the fix in trunk, so people can try it. A reason the impact is going to be limited, is that usually when defining a GADT for type witnesses, one only lists predefined types, and uses another mechanism for user defined types, like what is done in Core. If you use a mechanism based on equality witnesses, (lack of) injectivity already came in the way before, so this is not a new phenomenon. For other applications of GADTs, you are defining type indices yourself, so you just have to be careful to use concrete types instead of abstract ty= pes. Jacques Garrigue=