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 629B07FA5C for ; Wed, 22 Jun 2016 08:55:04 +0200 (CEST) IronPort-PHdr: 9a23:DS5ZfRbUUrbfrm9/e+/+gML/LSx+4OfEezUN459isYplN5qZpcW6bnLW6fgltlLVR4KTs6sC0LuO9fi5Ej1eqb+681k8M7V0HycfjssXmwFySOWkMmbcaMDQUiohAc5ZX0Vk9XzoeWJcGcL5ekGA6ibqtW1aJBzzOEJPK/jvHcaK1oLshrj0o8SYMlsArQH+SI0xBS3+lR/WuMgSjNkqAYcK4TyNnEF1ff9Lz3hjP1OZkkW0zM6x+Jl+73YY4Kp5pIZoGJ/3dKUgTLFeEC9ucyVsvJWq5lH/Sl6g73EGU2gS2iFDAwXf4QuyCpj4uDH7u+47wyKaMNf7V5g7XD2j6+FgTxq+2wkdMDtsulnaltB9lupy5lqcvR9yz4fQKsnBLPNjZKDQcdoebWVEV8dVESdGB9XvPMM0E+MdMLMA/MHGrFwUoE77XFH0CQ== Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=paurkedal@gmail.com; spf=Pass smtp.mailfrom=paurkedal@gmail.com; spf=None smtp.helo=postmaster@mail-oi0-f43.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of paurkedal@gmail.com) identity=pra; client-ip=209.85.218.43; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="paurkedal@gmail.com"; x-sender="paurkedal@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of paurkedal@gmail.com designates 209.85.218.43 as permitted sender) identity=mailfrom; client-ip=209.85.218.43; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="paurkedal@gmail.com"; x-sender="paurkedal@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-oi0-f43.google.com) identity=helo; client-ip=209.85.218.43; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="paurkedal@gmail.com"; x-sender="postmaster@mail-oi0-f43.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B8AABjNWpXhivaVdFeg1yBNQaoBJJvgXqGF4EsBzgUAQEBAQEBAQERAQEBCAsLCSEvgjKCHAEWEQQZARsdAQMSEA0CAiYCIwEBEQEFASITGweHcwEDF6RKgTE+MYs7gWqCWQWHNwoZJw1SgyMpAgYQcYw2hH6CWgEEjXeKUTQBgTCLAoF6gWmIAIU6iAyGMBIegQ8egjEKFAuBTjoyiS0qgRoBAQE X-IPAS-Result: A0B8AABjNWpXhivaVdFeg1yBNQaoBJJvgXqGF4EsBzgUAQEBAQEBAQERAQEBCAsLCSEvgjKCHAEWEQQZARsdAQMSEA0CAiYCIwEBEQEFASITGweHcwEDF6RKgTE+MYs7gWqCWQWHNwoZJw1SgyMpAgYQcYw2hH6CWgEEjXeKUTQBgTCLAoF6gWmIAIU6iAyGMBIegQ8egjEKFAuBTjoyiS0qgRoBAQE X-IronPort-AV: E=Sophos;i="5.26,508,1459807200"; d="scan'208";a="223395616" Received: from mail-oi0-f43.google.com ([209.85.218.43]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 22 Jun 2016 08:55:03 +0200 Received: by mail-oi0-f43.google.com with SMTP id f189so8835199oig.3; Tue, 21 Jun 2016 23:55:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=9Y57MeuxcGR8gqiW60AzCjyocvYBtm/VbXBjAuGZg/w=; b=tJqkkgLXJBVXGgpgWGUN9W7YPlx8Id4/fo8TRYpcQOsVuzx4VOPa522pIsVKEM9GgY HJuJudSMX9lrVFwQkEAhWqcnQDAby6Bv2QsqkN748sbmjlyEa/WYh8VKFhr6oXgvE5Xf dNgTQCbRPoXpv3hrNkZAPzkOWiL+cW6taF6VYNYx6a3lAFtrWytxVDDlG0uHnqmz3wiC 74jZMeGdnOfn2bL8B6pRcRP59CEuWXTL2L3lugav6oUqIKReoXoIRbl8bgAOZjSo2/Xx 7BP8opzPBImN8wmC9Wprnb30lF5uBdsAJHbbuUWJAC+51hGSXkDM3xGMfskGjUh67agS fymQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=9Y57MeuxcGR8gqiW60AzCjyocvYBtm/VbXBjAuGZg/w=; b=UM18VAB/d6Q7m8hsiNiVMpTGU1GoR4fu9j37O1T0CIqL7l0oAKKjkExKhiwN1KokzY 7rfFsb9hbBQfzEWI9gaIiwnBmgLG56YiwRIe9hsDHRUeVuuzgiR3GgdB0vbGgqHRxRH3 8MUjMXepq31gB9MxMY7fHANhazcqAdF3TZ1hIDXYkf78ZmsZ385h9oiguD/6cMKrTGS9 ORAoT59bfxBPRusqtfmvC/a8OfM+nWYnMKj54ChZ6l+W79TpnWCs0LbcpxvJsQ52WV+E JjslYmZ3oHM4J/BVGyXkhs1KYnLPnNrJJRJ8tinCbhWy5y5I/AWUEXlg+9aSnwRzH6+C yhuA== X-Gm-Message-State: ALyK8tIlTOUPXnnDpET/cWV+3J2Nji5VPeWos4yK2sSMGqMBxZAi8hw30hJ8uiH/+R6nwDezIybMaepYB41yhw== X-Received: by 10.202.245.12 with SMTP id t12mr722030oih.185.1466578501987; Tue, 21 Jun 2016 23:55:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.228.201 with HTTP; Tue, 21 Jun 2016 23:55:01 -0700 (PDT) From: "Petter A. Urkedal" Date: Wed, 22 Jun 2016 08:55:01 +0200 Message-ID: To: Gabriel Scherer Cc: Damien Doligez , caml users Content-Type: text/plain; charset=UTF-8 Subject: [Caml-list] Versioned deprecations? On 21 June 2016 at 17:48, Gabriel Scherer wrote: > (3) As Daniel pointed out, we need a better understanding of how to make > code written using new stdlib functions compatible with older OCaml > versions. So far we've used ad-hoc solutions on each situation, and it was > barely manageable despite the small number of instances. (Bytes: in findlib; > opaque_identity: clever hack; String ascii functions: no solution). I guess the issue with the ASCII string functions is similar to one I hit myself. The introduction of `[@@deprecated]` helps a lot in evolving interfaces, but there is the one annoying case when one wants to give the identifier a new incompatible definition right away. The option seems to be to first rename, leaving a deprecated alias, then wait for code to adapt before reusing it. If the new definition is introduced before, it needs to be under a temporary name, leaving another deprecation. This made me think of versioned identifiers as a possible way to mitigate the issue. The library interface would read e.g. val find : key -> 'a t -> 'a [@@obsolete "2.0.0"] val find : key -> 'a t -> 'a option and tag the definition similarly. The client code would announce against which version of the library it was written. At the point of reference, the ppx or compiler would substitute latest versioned identifier succeeding the announced version, or fall back to the unversioned definition. A purely syntactic transformation, though the transformer must inspect the full signature of the module containing the unversioned identifier. The compiler issues a warning whenever an obsolete identifier is used. What version of a library the client code requests is less important, as long as no obsolete identifiers are chosen. (That is just saying that the user of a library shouldn't need to bother about updating version requests before a warning occurs.) There is a notable limitation of this solution, namely that when a versioned deprecation occurs in a signature which types a functor argument, the effect is opposite of what we want: The client code would be responsible for filling in the obsolete definitions. Though, solving this case seems to require a substantial changes to the module system.