This is a nice clarification to have regarding the standard library - thank you for writing it up!

@alainfrisch You mention several examples of things which would not be accepted. I think that list makes a lot of sense, particularly with opam in wide use. It would be useful to have a matching list of suggested areas for contribution. For example, would IO convenience functions be welcome? Adding functions to make the interfaces to modules such as List and Array consistent? Conversion to/from iterators like @c-cube's Gen module works with?

Typos fixed. Thanks for spotting them!

Adding functions to make the interfaces to modules such as List and Array consistent?

This is what I meant by "filling obvious gaps".

Conversion to/from iterators like @c-cube's Gen module works with?

Could be covered by "facilitate communication between independent external libraries".

I don't want to go into specific suggestions, though. They would be less consensual. Proposals for concrete suggestions could come later and should perhaps be collected elsewhere.

I don't want to go into specific suggestions, though. They would be less consensual. Proposals for concrete suggestions could come later and should perhaps be collected elsewhere.

That makes sense. Could you indicate where/who to ask if a specific type of contribution would be welcome? A contributor could create a full PR but if the contribution wouldn't be accepted regardless of implementation details it would be nice to know that beforehand.

This is pretty cool. I will find some time to submit some carefully selected parts of containers for addition into the stdlib. Would "promoting safer programmation patterns" also be a good reason to integrate into the stdlib? Something linked to providing non-raising alternatives to functions, and better management of resources (channels, etc.).

Could you indicate where/who to ask if a specific type of contribution would be welcome?

That's not really specific to the stdlib (although more users could feel comfortable contributing to the stdlib rather than the language or compiler). Perhaps just ask on caml-list, or caml-devel, or create a Mantis ticket or Github "placeholder" PR? It could make sense to have something more formalized, but I've no concrete suggestion for now.

It could make sense to have something more formalized, but I've no concrete suggestion for now.

Again, this makes sense. Having this text to point interested contributors to is already a big step.

May I suggest to take inspiration from work done by F# , especially this one :
https://github.com/fsharp/FSharpLangDesign/blob/master/FSharp-4.0/ListSeqArrayAdditions.md
Concerning Seq, several OCaml iterators are available (my favorite being https://github.com/c-cube/sequence).

Note:
Without opening a 361st discussion (yes, I counted them...) can we really hope that things will move this time ?
It is often said that lack of people and resources at INRIA explain the relative stagnation of the std lib.
However, there is now on earth a person healthy (well, I hope ...),
graduate (Polytechnique, brand new PhD), available, responsive, competent (rewriting/improving Batteries, writing Containers) and, icing on the cake, working at INRIA.
So please, discuss, correct, improve AND accept Mr. Simon 'c_cube' Cruanes' proposals.
(sinon que de temps et de compétences gaspillés, damn it, c'est ... énervant )

While the existence of a competent engineer graduating from Polytechnique is certainly worth celebrating, this ticket is not about discussing specific extensions of the stdlib, but about making our policy w.r.t. external contributions clearer and fighting some widespread misconceptions. If you or @c-cube feel like the community could benefit from having parts of Containers included in the stdlib, please make a concrete proposal.

Btw, another misconception is apparent in your note: while INRIA remains the owner of the project and the employer of its two leaders or other core developers, most people with commit rights are not affiliated to INRIA, and many recent contributions even came from people external to that group.

@alainfrisch when this is merged, I will indeed make a few proposals in new tickets :-)

No misconception at all I think. I know that a great majority of the 73 contributors is external to INRIA.
And look, I'm n°56 on this list and it took 5 months and 2 PR before the correction of simple typos was accepted. Grrrr... it's not so easy to enter in the OCaml Hall of Fame :)
My note was only about 'the lack of people and resources at INRIA' (a very common answer given for example by gasche,Yaron Minsky,Fabrice Le Fessant ...).
But anyway, thousands of proposals of c-cube and others are coming, some will be accepted (yes ?) and OCaml will finally rule the world.
P.S. coming from a ENS guy, your remark about Polytechnique seems a big troll :D

What worries me with that announcement is that we are going to get one or two functions added here and there with every major version of OCaml which:

1. As a developer (especially of packages) is a huge pain to deal with (see e.g. re.1.6.1 - via opam-publish opam-repository#6801 (comment))
2. Will fail to have a coherent vision for the design of the stdlib. There's no actual design going it's ad-hoc functions shoved in the library without much thinking over the larger design of the library or how these functions can interact together to provide a meaningful toolset.

#626 is a good example of this.

@dbuenzli What are you suggesting? The complete status quo of the stdlib, and then a year-long process to design the "Next Stdlib" (with no guarantee that it produces something better than current alternatives)? Can you explain which of the recent additions to the stdlib are "bad" for you?

@dbuenzli What are you suggesting? The complete status quo of the stdlib, and then a year-long process to design the "Next Stdlib" (with no guarantee that it produces something better than current alternatives)?

No. I'm suggesting that someone who tries to add a function to the String module does a complete thought and redesign of it (in the limits of the backward compatibility requirements) rather than just add the function he's looking for and finds missing at the moment.

The current suggested process is not the way to design coherent systems and is very annoying to the end user of the system.

@dbuenzli It cannot be a "complete thought and redesign" if retrocompatibility matters, though. I dislike the small, incremental additions too, but any significant modification of the stdlib should still be a conservative extension (or it will break user programs).

What I'd like to see a committee that would build on the interfaces from alternatives to the stdlib (core, batteries, containers, etc.) and agree on a common set of functionalities to add (as consistently as possible) to the current stdlib.

For instance, we could agree that every module (if it makes sense) should provide:

type t (* maybe polymorphic *)
val equal : t -> t -> bool
val compare : t -> t -> int
val hash : t -> int
val print : Format.formatter -> t -> unit

for data structures, stuff like

val to_iterator : 'a t -> 'a iterator
val of_iterator: 'a iterator -> 'a t

etc. Looking at batteries, there is plenty of very useful functions that could be added in a consistent way. Since batteries has been developed for a while, one can reasonably think that its interfaces for "common" modules (option,list,string,result,etc.) are sufficient for most use-cases.

Of course this takes work, but it's better than having 3 new functions per release.

edit: I would totally participate in such a committee, and am willing to contribute code from containers.

@dbuenzli It cannot be a "complete thought and redesign" if retrocompatibility matters, though.

Please pay attention to my words, I said "in the limits of backward compatibility requirements".

Since batteries has been developed for a while, one can reasonably think that its interfaces for "common" modules (option,list,string,result,etc.) are sufficient for most use-cases.

I'm not interested in sufficient, I'm interested in well designed. Sufficient allows to write crap programs, I want to write good programs. When I designed astring last year I had a look at batteries' String module and I didn't find it well designed at all. In general I don't think that organic and comittee driven design works.

Then we should wait for you to re-design perfectly every piece of the standard library, because you know better than any hypothetical committee? That's nice.

I would find it awesome if we had a perfectly designed standard library with what you need to write good programs. However, many existing programs rely on the stdlib and we must not break them, so that rules out re-designing anything existing (you seem to imply those programs are "crap", btw, which is not constructive at all; my code relies on the stdlib). If you think you can do a good design on top of what exists, I'm all ears. In the mean time, I hope there will be a discussion on a "sufficient" extension of the stdlib, and I agree that it needs some vision and not just a collection of random additions.

Then we should wait for you to re-design perfectly every piece of the standard library, because you know better than any hypothetical committee? That's nice.

Where did I say that this had to be me ? Please reread what I said here and stop wasting my time.