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 1D8037FA87 for ; Tue, 21 Jun 2016 13:56:44 +0200 (CEST) X-IronPort-AV: E=Sophos;i="5.26,503,1459807200"; d="scan'208";a="223274848" Received: from macrame.saclay.inria.fr (HELO [10.0.1.8]) ([193.55.177.65]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Jun 2016 13:56:44 +0200 From: Damien Doligez Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5E818FB5-6908-4E29-838E-C6A2836F60CE@inria.fr> Date: Tue, 21 Jun 2016 13:56:43 +0200 To: caml users Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Subject: [Caml-list] About contributions to the Standard Library Dear Ocaml contributors and users, I would like to call to your attention the section below, which was recently added to the CONTRIBUTING.md file in the OCaml source repository. Have a nice day, -- Damien ## Contributing to the standard library Contributions to the standard library are very welcome. There is some widespread belief in the community than the stdlib is somehow "frozen" and that its evolutions are mostly driven by the need of the OCaml compiler itself. Let's be clear: this is just plain wrong. The compiler is happy with its own local utility functions, and many recent additions to the stdlib are not used by the compiler. Another common and wrong idea is that core OCaml maintainers don't really care about the standard library. This is not true, and won't be unless one of the "alternative standard" libraries really gains enough "market share" in the community. So: please contribute! Obviously, the proposals to evolve the standard library will be evaluated with very high standards, similar to those applied to the evolution of the surface langage, and much higher than those for internal compiler changes (optimizations, etc). A key property of the standard library is its stability. Backward compatibility is not an absolute technical requirement (any addition to/of a module can break existing code, formally), but breakage should be limited as much as possible (and assessed, when relevant). A corollary is that any addition creates a long-term support commitment. For instance, once a concrete type or function is made public, changing the exposed definition cannot be done easily. There is no plan to extend dramatically the functional domain covered by the standard library. For instance, proposals to include support for XML, JSON, or network protocols are very likely to be rejected. Such domains are better treated by external libraries. Small additions to existing modules are much simpler to get in, even more so (but not necessarily) when: - they cannot easily be implemented externally, or when - they facilitate communication between independent external libraries, or when - they fill obvious gaps. Of course, standard guidelines apply as well: proper documentation, proper tests, portability (yes, also Windows!), good justification for why the change is desirable and why it should go into stdlib. So: be prepared for some serious review process! But yes, yes, contributions are welcome and appreciated. Promised.