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 c5ff346549e7 (Postfix) with ESMTPS id 974365D4 for ; Fri, 21 Aug 2020 12:19:15 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.76,335,1592863200"; d="scan'208";a="464222775" Received: from prod-listesu18.inria.fr (HELO sympa.inria.fr) ([128.93.162.160]) by mail2-relais-roc.national.inria.fr with ESMTP; 21 Aug 2020 14:19:12 +0200 Received: by sympa.inria.fr (Postfix, from userid 20132) id A8990E0C5A; Fri, 21 Aug 2020 14:19:12 +0200 (CEST) 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 41404E0AD1 for ; Fri, 21 Aug 2020 14:19:11 +0200 (CEST) Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=francois.bobot@cea.fr; spf=Pass smtp.mailfrom=francois.bobot@cea.fr; spf=None smtp.helo=postmaster@sainfoin-smtp-out.extra.cea.fr X-IronPort-AV: E=Sophos;i="5.76,335,1592863200"; d="scan'208";a="464222759" X-MGA-submission: =?us-ascii?q?MDGB5OAo/A+ekrPfiaPVqeumyjEPVmtwKHJJUZ?= =?us-ascii?q?Md/8AcoHruNyrf+xabpl+C1yF/x8vHGWiNK2wfCWbY88w1wB+viQj9iA?= =?us-ascii?q?r5bgIw6ZBl+sIovUABfmkrDBoQUVo5XHFbUrFfyj1A4lhV+tijtkCpPX?= =?us-ascii?q?VE6tpEvePy2GOwN9DV/gVFnA=3D=3D?= Received: from sainfoin-smtp-out.extra.cea.fr ([132.167.192.228]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Aug 2020 14:19:11 +0200 Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 07LCJABP015039 for ; Fri, 21 Aug 2020 14:19:10 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AE051204209 for ; Fri, 21 Aug 2020 14:19:10 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A3E632041CD for ; Fri, 21 Aug 2020 14:19:10 +0200 (CEST) Received: from [10.8.35.72] (is231324.intra.cea.fr [10.8.35.72]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 07LCJAgG002621 for ; Fri, 21 Aug 2020 14:19:10 +0200 From: =?UTF-8?Q?Fran=c3=a7ois_Bobot?= To: OCaml Mailing List Message-ID: <71ff7d61-6899-9b05-4c01-3984d47698ca@cea.fr> Date: Fri, 21 Aug 2020 14:19:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: [Caml-list] Tools for helping backward compatibility? Reply-To: =?UTF-8?Q?Fran=c3=a7ois_Bobot?= X-Loop: caml-list@inria.fr X-Sequence: 18224 Errors-To: caml-list-owner@inria.fr Precedence: list Precedence: bulk Sender: caml-list-request@inria.fr X-no-archive: yes List-Id: List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: List-Archive: Archived-At: Hi all, Backward compatibility helps a lot a community of packages to move forward. There are other possibilities like being able to co-install multiple version of a library, but having backward compatibility is still a huge simplification of the problem. Strongly typed language makes it easier to break backward compatibility since more things are checked, dynamically typed language let more thing pass for the best and too often for the unpredictable worst. So I'm discussing here only backward compatibility at the typing phase. I'm wondering if typing have been used for helping to ensure backward compatibility of an API. In a sense it is at the core of the module system, adding a signature to a module ensure that whatever you change in the implementation if you don't modify the signature any user is going to type. However it doesn't help you if you modify the signature: - Changing anything meaningful in a module can break someone who uses `module type of`. - Adding a type can break someone who includes the module - Adding an optional argument to a function can break someone who uses it not fully applied. - Removing a value from the definition of a signature can break someone who uses it as a functor parameter - Adding a constructor breaks all matching without final wildcard However they are modifications of an API that could be seen as normal and should not break sane user. In order to not have to cross our fingers, we could specify how we could modify in the future our API so that users are warned when they use the API in a way that could be broken in the future: - In the future this type will not be modified: so the user can pattern match all the cases - In the future no new values will be added: so the user can open the module as much as you want - In the future new cases can be added to an ADT: so the user need to use a _ - In the future optional arguments can be added to the values of this module: so the user need to apply fully Then three checks can be provided: - Given an API, the guarantees of the possible modifications of the API, and a user code: check if the user code can be broken by future modifications of the API - Given an API, the guarantees of the possible modifications of the API, and a new version of the API: check if the new version follows the guarantees - Given an API, the guarantees of the possible modifications of the API, and new guarantees of the possible modifications of the API: check if the new possible modifications are included in the old one I believe the analysis can be done after the normal OCaml typing (on typedtree), so it can be external to the OCaml typer. But it still put pressure on what the Ocaml typer does accept. (Perhaps "API migration: compare transformed" at OCaml 2020 next week will have some answers!) Best, -- François