I have written a small retro-compatibillity package for the new Seq module (https://github.com/c-cube/seq) and I wonder if it makes sense to migrate it under the “ocaml” github organization.
This seems like a good opportunity to advertise OSeq which adds a lot of convenient combinators on top of seq (like, for example, rresult for result).
Maybe we should consider gathering these under a common repo and package. We already have uchar (hosted at ocaml maintained by me) and result (hosted at janestreet maintained by @jeremiedimino). It’s also less painful for end users, just one package to add to your opam file.
So what about asking for a repo for this on the ocaml github organization ? I would suggest stdlib-forward for the name (feel free to suggest a better name).
Agreed, it would be better to have a single package for all these modules. I find the name stdlib-forward a bit long but I don’t have a better suggestion.
Well, there is already stdcompat which kind of provides something comparable to compatibility packages (though from what I’ve seen it seems to go much further), so it would probably be best to avoid a name that’s easily confused with that ?
An ocaml/ repository makes sense to aggregate these. I’m in favour of stdlib-extra, to reflect that these were once part of the standard library, but are now extra packages.
We are talking about the other way round. Also with all these alternative stdlibs such a name would be rather confusing.
I think what we want is precisely to integrate everything into stdcompat, and move it into the ocaml organization. stdcompat provides the mechanism we want to expand.
Doesn’t stdcompat redefine the whole stdlib in a consistent way? Here I believe @dbuenzli is thinking of the minimalistic backward-compatibility packages such as uchar and result that should mostly be used by 3rd party libraries or stdlib extensions.
I personally like the name stdlib-forward because it’s not “extra” features, but just a way to use the new stdlib features consistently across OCaml versions.
Yes @c-cube has my thinking. Let us start this the easy way by just gathering the new modules as they are introduced. More evolved schemes may require a non-trivial amount of time and can be thought about later. Regarding the name I asked Damien Doligez if we could get stdlib-fwd to make it shorter as requested by @jeremiedimino.