Comment author: @gasche

Meh.

3. Non-labeled modules use optional arguments, which are sometime used as a way to preserve (partial) backward-compatibility while adding more parameters to a function. That's not the same as naming mandatory arguments.

4. I don't see exactly how that is a split, given that it is rather trivial to switch from one style to the other, and that pieces of code using either can link with other pieces making a different choice seamlessly. I could see how different and incompatible cooperative concurrency interfaces could split a community, I don't see anything like that here.

5. In practice most beginners follow what they are taught, and as far as I am aware most people use other libraries from boot (eg. Real World OCaml uses Core), or just rely on the non-labeled function. But then if a teacher decided to encourage labeled arguments, I don't see an issue with that.

I think there is a case for deprecating library modules or compiler-distribution tools that have arguably better alternatives out there (Stream, ocamlyacc). I'm rather skeptical of the current proposal.

Comment author: @alainfrisch

I support this, but we need to come up with a migration story. Would this simply be an external package with the current snapshot of those *Labels modules? (And then give the project to the community if anyone is interested to maintain it.) That would still require to tweak the build system of projects depending on those modules.

Comment author: @alainfrisch

as far as I am aware most people use other libraries from boot

Any volunteer to parse the opam repo to get some statistics? Knowing how much open-source projects depend on core or batteries would be a useful piece of information for all cross-cutting discussions about the future of the stdlib.

I don't see exactly how that is a split

Even if it is not difficult to switch, not being able to copy/paste some code e.g. from StackOverflow or a tutorial adds useless friction.

Comment author: @dbuenzli

@gasche As a user every choice to make has a cost. For the experience of the system I think it's good if we try to eliminate choices whose costs are larger than the benefits.

@Frisch the first step would be to mark the modules as deprecated for a few versions. We could then migrate them to a separate cma for a few other versions (requiring to link against it to use them) and eventually split them off.

Comment author: @dbuenzli

@Frisch opam list has the info.

opam list --depends-on core -s | wc -l
58
opam list --depends-on batteries -s | wc -l
33
opam list --depends-on containers -s | wc -l
5
opam list -a | wc -l
1322

Comment author: @alainfrisch

@dbuenzli Very useful, thanks! Any automated way to group the result by maintainer? (It's not crazy to believe that a good fraction of packages depending on Core come from Jane Street.)

Comment author: @gasche

I find these statistics interesting, but note that Daniel was mentioning choice fatigue "especially among newcomers", and I don't think that newcomers and OPAM package authors make the same technological choices -- or even evaluate them in the same way. (I don't know of newcomers using Batteries (or *Labels for that matter), but maybe some teachers do rely on it?)

That said, I'm just "meh" on that suggestion and I appreciate the effort that you (Alain, Daniel) are ready to pour in stdlib work. If you both agree that something is a good idea, please roll over my opinion with glee.

Unlikely to happen. Let's close this.

Closing as suggested.