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 86F947FA5C for ; Wed, 22 Jun 2016 17:33:18 +0200 (CEST) IronPort-PHdr: 9a23:W8vFSB3RonOrkD/DsmDT+DRfVm0co7zxezQtwd8ZsegfK/ad9pjvdHbS+e9qxAeQG96Ks7Qc0KL/iOPJYSQ4+5GPsXQPItRndiQuroEopTEmG9OPEkbhLfTnPGQQFcVGU0J5rTngaRAGUPj3a1CamHCu9zlaQky5blstYLyuUqfpzO2Pn9io/JPSZwgazBGcWphVaCuMkAPKq8MNipFjIKtigjHAo39PZvgEjTgwfQHbt1/G68yx5J9u9ThL87JkrpYYEPbMRLkjVbFTEBghNmk04oWr6UiCHkOz4S4zW28MkxdMSzPO7BzgU4255iTzvPB81S3cJsb2QKo5Qxyt6q5qTFnjjyJRZBAj92SCqNF2l6Vdr1qFplQrx4zPJo2cLvlwf7jdVdwfTGtFGM1WUnoSUcuHc4ITAr9Zbq5jpI7nqg5L8EKz Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=ljs.darkfish@gmail.com; spf=Pass smtp.mailfrom=ljs.darkfish@gmail.com; spf=None smtp.helo=postmaster@mail-pf0-f172.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of ljs.darkfish@gmail.com) identity=pra; client-ip=209.85.192.172; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="ljs.darkfish@gmail.com"; x-sender="ljs.darkfish@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of ljs.darkfish@gmail.com designates 209.85.192.172 as permitted sender) identity=mailfrom; client-ip=209.85.192.172; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="ljs.darkfish@gmail.com"; x-sender="ljs.darkfish@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-pf0-f172.google.com) identity=helo; client-ip=209.85.192.172; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="ljs.darkfish@gmail.com"; x-sender="postmaster@mail-pf0-f172.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BuAQAtr2pXf6zAVdFehBR9BqVYBoMxkxkihXUCgSUHPBABAQEBAQEBAREBAQkLCwkfMYIyghoBAQEDARILBh0BGxACCwEDAQsGBQsNDR0CAiEBAREBBQEKEgYTEgIHB4dzAQMPCA6mBIExPjGLO4FqgloFhy0KGScDClKDIwEBAQEGAQEBAQEBAQEXAgYQhU+FFYJDgUkQUYJUgloFhgJLDIFFhVpzP4QghH80hgiFaUKBeoFpToQFiGeIDYYwEh6BDw8mghoKAxyBWS8yiS0CJAeBFwEBAQ X-IPAS-Result: A0BuAQAtr2pXf6zAVdFehBR9BqVYBoMxkxkihXUCgSUHPBABAQEBAQEBAREBAQkLCwkfMYIyghoBAQEDARILBh0BGxACCwEDAQsGBQsNDR0CAiEBAREBBQEKEgYTEgIHB4dzAQMPCA6mBIExPjGLO4FqgloFhy0KGScDClKDIwEBAQEGAQEBAQEBAQEXAgYQhU+FFYJDgUkQUYJUgloFhgJLDIFFhVpzP4QghH80hgiFaUKBeoFpToQFiGeIDYYwEh6BDw8mghoKAxyBWS8yiS0CJAeBFwEBAQ X-IronPort-AV: E=Sophos;i="5.26,509,1459807200"; d="scan'208,217";a="223502126" Received: from mail-pf0-f172.google.com ([209.85.192.172]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 22 Jun 2016 17:33:16 +0200 Received: by mail-pf0-f172.google.com with SMTP id t190so18758290pfb.3; Wed, 22 Jun 2016 08:33:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5Xj0g7MZbQwV2+JvxkxOcn0Y9KaJFMRybYkWa3A9DZ4=; b=JzgY6bUliVWxrwZFX1IyBp/pWSVIia1WQqWjY1A2fJmNTiogM8dpkpDjySkm0dg861 i4hG9h/w6uddM4N4oTZ81PHW4dVCr+WvtdOyEJWxXt8H9P99MkUAb7i5mhKMtbMQYW93 s3zoVTZ65DEdx2otFsDBHmgji++KvgA8IP2CGybqByRiXGCCibVX0s/LdoHagOOHWrk/ fsnHiguQa4Wm+uwyQ0KkgumsBjj58EgrMV5rCVib4HyXiBwzJVIGDHcDULjxBMdq7YuA Kcv56lyXFXGzQIK/GqvpzNY1SbSHc0bmD+agKp0b9xz/sWrrMaVnshbEc+jYQMg3oc8s OxWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5Xj0g7MZbQwV2+JvxkxOcn0Y9KaJFMRybYkWa3A9DZ4=; b=lkO5pvFopKpOUTGKR6lPLlyZTpXt96l79M4FsedMXdxZpbp+9utSRjiOL8BBb59hsV IU4hppAD7XScKhqa8nH96oaJAiQN/Qp69W717wLsXynG58uk2vBMnBk5uf5vmBylYZHO b3QzaYuHxHwY0WvwiKLmMKjL2T4Mfh79RVfVcp37kar2Xb2PHXOHvQ161XJEkQQPbvP2 4VkDwJybi+BF0aRs/fo8deGiD01QefRMF1EQAWm8F2nJ4S/2aiP4ZjPwzsLvYO/996d8 /JbuEzH4a6oKmSE8rAP6r7z6u5fHXUx9uGNbpSDmPEWFqlFIE8cZd41B7tzagyAiOqV+ UXvQ== X-Gm-Message-State: ALyK8tKG/qbiuMrc/9LVjudAO0OBPAV+FpOyRbj6dnQfn2D6MOATmAEjVRPRG2P2eOFPfp0PoHbKaMKClV6yXA== X-Received: by 10.98.93.65 with SMTP id r62mr34665054pfb.114.1466609594659; Wed, 22 Jun 2016 08:33:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.15.8 with HTTP; Wed, 22 Jun 2016 08:33:14 -0700 (PDT) In-Reply-To: References: <5E818FB5-6908-4E29-838E-C6A2836F60CE@inria.fr> From: Junsong Li Date: Wed, 22 Jun 2016 23:33:14 +0800 Message-ID: To: Gabriel Scherer Cc: Damien Doligez , caml users Content-Type: multipart/alternative; boundary=001a113ec606e9f9760535dfa751 Subject: Re: [Caml-list] About contributions to the Standard Library --001a113ec606e9f9760535dfa751 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for calling it out. Well, this actually confuses me a bit. Is the ultimate goal for evolving the builtin library another "Batteries"? I ask this because it does not sound like you're actually calling for a battery-included stdlib. If not, here is my second question: Why now? What's the problem for current stdlib? Thanks. On Tue, Jun 21, 2016 at 11:48 PM, Gabriel Scherer wrote: > In my experience, reviewing propositions for new functions to the standard > library is very delicate and a rather stressful process. I think that > guidelines on how to discuss, review and validate these proposals would > help making it easier. Do we have some, or do we intend to have some in t= he > short-term future? > > What makes standard library additions hard to review is that the review > is, *in essence*, a session in bike-shedding. We can all recognize > bike-shedding and it makes nobody happy, but when doing API design > bike-shedding is very much the point. So standard library addition > discussions, by design, tend to make people frustrated. I think policies = on > how to contribute to these discussions, and how decisions will be made, > could help alleviate some of that frustratoin. > > For the 4.03 deadline we had a very simple policy: we would only accept > functions whose name and function were completely obvious and > non-objectionable ("map2" for example). If anyone in the discussion had a > reservation about a function, we did not include it. In retrospect, I thi= nk > that having agreed on that was an excellent choice, it made it easy to > discuss those proposals. > > Now of course this specific policy was only intended short-term, and is > probably too conservative to handle future stdlib changes. Is there a > reasonable relaxation of that policy that people would be willing to agree > on? Or maybe it would be possible to explicit the fact that there are > several kind of contributions, some that fit certain well-defined criteria > (such as the one above: being obvious and completely uncontroversial) and > are expected to be processed/review/decided in due diligence, and some th= at > are outside these bounds and should be *expected* to devolve into long and > possibly-frustrating discussions? > > > ## Notes > > (1) Discussing function names or seemingly-minor API details is not > necessarily an exercise in subjectivity. There are precise (formal) things > that can be said about properties of certain interfaces compared to other= s, > as we discussed with Daniel B=C3=BCnzli in a memorable past discussion in > GPR#10. Taking time to make decisions can result in measurably better > designs, and the importance of unit testsuits *and* property testing to > help and structure API design cannot be under-estimated.) > > > (2) I think part of the stress comes not from the specific status of > standard library (it exists with other libraries), but because of > backward-compatibility requirements: one cannot get it wrong on the first > time. I think this strong requirement is a good choice for the standard > library, despite its costs. > > > (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 solutio= n). > > On Tue, Jun 21, 2016 at 7:56 AM, Damien Doligez > wrote: > >> 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. >> >> >> -- >> Caml-list mailing list. Subscription management and archives: >> https://sympa.inria.fr/sympa/arc/caml-list >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >> Bug reports: http://caml.inria.fr/bin/caml-bugs >> > > --001a113ec606e9f9760535dfa751 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for calling it out.

Well, this a= ctually confuses me a bit. Is the ultimate goal for evolving the builtin li= brary another "Batteries"? I ask this because it does not sound l= ike you're actually calling for a battery-included stdlib.
If not, here is my second question: Why now? What's the pr= oblem for current stdlib?

Thanks.


On Tue,= Jun 21, 2016 at 11:48 PM, Gabriel Scherer <gabriel.scherer@gmail.= com> wrote:
In my experience, reviewing propositions for new functions= to the standard library is very delicate and a rather stressful process. I= think that guidelines on how to discuss, review and validate these proposa= ls would help making it easier. Do we have some, or do we intend to have so= me in the short-term future?

What makes standard library addit= ions hard to review is that the review is, *in essence*, a session in bike-= shedding. We can all recognize bike-shedding and it makes nobody happy, but= when doing API design bike-shedding is very much the point. So standard li= brary addition discussions, by design, tend to make people frustrated. I th= ink policies on how to contribute to these discussions, and how decisions w= ill be made, could help alleviate some of that frustratoin.

Fo= r the 4.03 deadline we had a very simple policy: we would only accept funct= ions whose name and function were completely obvious and non-objectionable = ("map2" for example). If anyone in the discussion had a reservati= on about a function, we did not include it. In retrospect, I think that hav= ing agreed on that was an excellent choice, it made it easy to discuss thos= e proposals.

Now of course this specific policy was only inten= ded short-term, and is probably too conservative to handle future stdlib ch= anges. Is there a reasonable relaxation of that policy that people would be= willing to agree on? Or maybe it would be possible to explicit the fact th= at there are several kind of contributions, some that fit certain well-defi= ned criteria (such as the one above: being obvious and completely uncontrov= ersial) and are expected to be processed/review/decided in due diligence, a= nd some that are outside these bounds and should be *expected* to devolve i= nto long and possibly-frustrating discussions?


## Notes

(1) Discussing function names or seemin= gly-minor API details is not necessarily an exercise in subjectivity. There= are precise (formal) things that can be said about properties of certain i= nterfaces compared to others, as we discussed with Daniel B=C3=BCnzli in a = memorable past discussion in GPR#10. Taking time to make decisions can resu= lt in measurably better designs, and the importance of unit testsuits *and*= property testing to help and structure API design cannot be under-estimate= d.)


(2) I think part of the stress comes not from the= specific status of standard library (it exists with other libraries), but = because of backward-compatibility requirements: one cannot get it wrong on = the first time. I think this strong requirement is a good choice for the st= andard library, despite its costs.


(3) As Daniel poin= ted out, we need a better understanding of how to make code written using n= ew stdlib functions compatible with older OCaml versions. So far we've = used ad-hoc solutions on each situation, and it was barely manageable despi= te the small number of instances. (Bytes: in findlib; opaque_identity: clev= er hack; String ascii functions: no solution).
<= div class=3D"HOEnZb">

On Tue, Jun 21, 2016 at 7:56 AM, Damien Doligez <damien.doligez@inria.fr> wrote:
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.=C2=A0 There is some=
widespread belief in the community than the stdlib is somehow "frozen&= quot;
and that its evolutions are mostly driven by the need of the OCaml
compiler itself.=C2=A0 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.=C2=A0 This is not true, and won'= ;t
be unless one of the "alternative standard" libraries really gain= s
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.=C2=A0 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).=C2=A0 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.=C2=A0 For instance, proposals to include support for XML, JSON, or network protocols are very likely to be rejected.=C2=A0 S= uch
domains are better treated by external libraries.=C2=A0 Small additions to<= br> existing modules are much simpler to get in, even more so (but not
necessarily) when:

=C2=A0 - they cannot easily be implemented externally, or when
=C2=A0 - they facilitate communication between independent external
=C2=A0 =C2=A0 libraries, or when
=C2=A0 - 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!=C2=A0 But yes, yes,
contributions are welcome and appreciated.=C2=A0 Promised.


--
Caml-list mailing list.=C2=A0 Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocam= l_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs


--001a113ec606e9f9760535dfa751--