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 016DA7FE44 for ; Fri, 8 Jul 2016 16:01:35 +0200 (CEST) IronPort-PHdr: 9a23:MqG0Ux86fDMulv9uRHKM819IXTAuvvDOBiVQ1KB80ewcTK2v8tzYMVDF4r011RmSDN2dsKoP1buempujcFRI2YyGvnEGfc4EfD4+ouJSoTYdBtWYA1bwNv/gYn9yNs1DUFh44yPzahANS47AblHf6ke/8SQVUk2mc1EkfqKuQsWM3oye7KObw9XreQJGhT6wM/tZDS6dikHvjPQQmpZoMa0ryxHE8TNicuVSwn50dxrIx06vru/5xpNo8jxRtvQ97IYAFPyiJ+VrBYBfWRgvNWE44PrBIR/RSQrHsncVVGQbllxCHgXD/hX7dprrqCLmt/Ng1W+RPZuyBZ89Uy6j4qMjcxTohT0KLXZt/2jdkM19iORAqxKsvRFl64HRaYCRcvF5e/WOU8kdQD9oWs9QUWRvGIKnZItHW+MFNOde6YfnpkAFrTO6CBmtCuKpwThN0CyllZYm2vgsRFmVlDcrGMgD5TGN9I34 Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=alain.frisch@lexifi.com; spf=None smtp.mailfrom=alain.frisch@lexifi.com; spf=None smtp.helo=postmaster@mx30.yaziba.net Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of alain.frisch@lexifi.com) identity=pra; client-ip=82.138.71.21; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="alain.frisch@lexifi.com"; x-sender="alain.frisch@lexifi.com"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of alain.frisch@lexifi.com) identity=mailfrom; client-ip=82.138.71.21; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="alain.frisch@lexifi.com"; x-sender="alain.frisch@lexifi.com"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mx30.yaziba.net) identity=helo; client-ip=82.138.71.21; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="alain.frisch@lexifi.com"; x-sender="postmaster@mx30.yaziba.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DPAQD0sX9XfRVHilJbhD67YYYYAoEnPBABAQEBAQEBAREBAQsUCVCCMoIaAQEEASMVQRALGAICJgICVwYBDAgBAYgkDK4hjz8BAQEBBgEBAQEBIoEBhSaBeIJVhEGDAYJaBZkUgVqMdYlNhV+QDAI1hBKKHgEBAQ X-IPAS-Result: A0DPAQD0sX9XfRVHilJbhD67YYYYAoEnPBABAQEBAQEBAREBAQsUCVCCMoIaAQEEASMVQRALGAICJgICVwYBDAgBAYgkDK4hjz8BAQEBBgEBAQEBIoEBhSaBeIJVhEGDAYJaBZkUgVqMdYlNhV+QDAI1hBKKHgEBAQ X-IronPort-AV: E=Sophos;i="5.28,330,1464645600"; d="scan'208";a="226090578" Received: from mx30.yaziba.net ([82.138.71.21]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Jul 2016 16:01:05 +0200 Received: from mta10.int.yaziba.net (unknown [217.117.151.14]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx30.yaziba.net (mx10.yaziba.net) with ESMTPS id B421A1A7AEF; Fri, 8 Jul 2016 16:01:04 +0200 (CEST) Received: from mta10.int.yaziba.net (localhost [127.0.0.1]) by mta10.int.yaziba.net (Postfix) with ESMTPS id EB013CA659; Fri, 8 Jul 2016 16:01:04 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mta10.int.yaziba.net (Postfix) with ESMTP id D7797CA75A; Fri, 8 Jul 2016 16:01:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at mta10.int.yaziba.net Received: from mta10.int.yaziba.net ([127.0.0.1]) by localhost (mta10.int.yaziba.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6nleQ2Q3EsSi; Fri, 8 Jul 2016 16:01:04 +0200 (CEST) Received: from [10.0.210.182] (unknown [185.23.92.144]) by mta10.int.yaziba.net (Postfix) with ESMTPSA id B24AECA659; Fri, 8 Jul 2016 16:01:04 +0200 (CEST) To: =?UTF-8?Q?Daniel_B=c3=bcnzli?= , Gabriel Scherer References: <5E818FB5-6908-4E29-838E-C6A2836F60CE@inria.fr> <7BDA5C9D56314AE6A0D9E07226862399@erratique.ch> Cc: Damien Doligez , caml users From: Alain Frisch Message-ID: <3004f713-9b54-b221-16c3-f4302abc1a44@lexifi.com> Date: Fri, 8 Jul 2016 16:01:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7BDA5C9D56314AE6A0D9E07226862399@erratique.ch> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-DRWEB-SCAN: ok X-VRSPAM-SCORE: -100 X-VRSPAM-STATE: legit X-VRSPAM-CAUSE: gggruggvucftvghtrhhoucdtuddrfeeltddrfedtgdejvdcutefuodetggdotefrucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpjgetkgfkueetnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefuvfhfhffkffgfgggjtgfgsehtqhertddtfeejnecuhfhrohhmpeetlhgrihhnucfhrhhishgthhcuoegrlhgrihhnrdhfrhhishgthheslhgvgihifhhirdgtohhmqeenucfkphepudekhedrvdefrdelvddrudeggeenucfrrghrrghmpehmohguvgepshhmthhpohhuth X-VRSPAM-EXTCAUSE: mhhouggvpehsmhhtphhouhht Subject: Re: [Caml-list] About contributions to the Standard Library On 07/07/2016 12:26, Daniel B=C3=BCnzli wrote: > The goal behind this move would not be to change the stdlib conservativen= ess and minimalistic approach but make it possible to use improvement made = to stdlib in older OCaml versions. The stdlib is somehow mechanically tied to the evolution of the runtime=20 system (new primitives being exposed) and the compiler (in particular=20 for the camlinternalXXX modules). There would necessarily be a new=20 version of the stdlib to be shipped together with a new version of the=20 system. If we stick to our new plan of making much more frequent=20 releases, there would probably be no need for intermediate releases of=20 the stdlib between versions of OCaml. So the question is really whether=20 "the" stdlib shipped with OCaml version N should work with OCaml version=20 M < N. Supporting in a single stdlib code base the current version of OCaml=20 (compiler+runtime system) and older ones would be as difficult as what=20 you describe in your point 1. And we would have the same dilemma about=20 waiting to use new features or not. (Even with the core team=20 conservatism, the stdlib is not so slow at adopting new language=20 features. E.g. GADTS for formatters, which is exposed in the interface,=20 or the internal use of inline records for performance reasons.) It=20 would be somehow a shame if the stdlib were the last one to benefit from=20 language improvements (at least in its implementation, but also in its=20 interface for new features). Considering that progressing on the stdlib is already quite hard, adding=20 such extra constraints and work seems a good way to ensure it remains=20 completely stalled. And who would decide until which version one should=20 maintain support? Now, nothing prevent people from backporting some chosen parts and=20 distribute e.g. a "stdlib 4.04 for OCaml 4.01", indeed outside the core=20 distribution. This might not be a complete coverage, but it could=20 provides some new goodies (e.g. String.split?) to people stuck with=20 older versions of OCaml. This could certainly be done by motivated=20 contributors outside the core team. In this context, I'm not so sure=20 about stubbing recent runtime features with failing implementations (if=20 a project depends on Ephemerons, it's unlikely to work with a failing=20 version of their API). > Finally I would just like to say that the current situation also has=20 its pluses as it encourages people to upgrade and hence follow the=20 general evolution the system. Good point. I've to say that I'm always a bit puzzled by the amount of=20 energy hobbyists put into supporting old versions of OCaml (compared to=20 e.g. ensuring continuously that their packages are ready for the next=20 one). Some industrial (or big academic) users being stuck with older=20 versions of OCaml (but many aren't) for good or bad reasons, but the=20 same ones are not likely to require the latest versions of third-party=20 libraries anyway, so this should not even be an incentive for library=20 authors to maintain such compatibility. Could you share the reasons for you to target 4.01 (and not, say 3.04)=20 today? Alain