Re: [Caml-list] OCaml maintenance status / community fork

[Goswin von Brederlow <goswin-v-b@web.de>]

Gabriel Scherer <gabriel.scherer@gmail.com> writes:

> There have been numerous "OCaml community meeting" discussing
> precisely these issues. I attended the 2008 meeting, and several
> aspects were discussed, including among others
> (1) the lack of openness of the compiler development (what you discuss here)
> (2) the apparent stagnation of the OCaml language itself
> (3) the lack of a comprehensive general-purpose set of software
> libraries that newcomers could just use as a standard starting point
> (4) the lack of visibility of user-contributed OCaml code, tools and
> libraries, or perceived difficulties to install and deploy such code
> (5) (related) the lack of communication of OCaml users about what they do
>
> You are singling out problem (1) as *the* problem with OCaml. I think
> this is more a reflect of your personal preferences (indeed, you are
> now a distinguished OCaml backend hacker) than a global analysis of
> the needs of the "OCaml community". I agree that (1) hasn't changed
> much since 2008; as you noted (at least from an external point of
> view), there are important human factors that make the situation
> difficult : not everyone can contribute to the compiler as there are
> both technical and social barriers to contribution.

It is *the* problem with ocamls upstream. Patches to the compiler and
core modules are not getting reviewed or accepted in a long time if at
all. And there is nothing you can do outside of the ocaml compiler to
fix that. Only option is to fork.

> (2) has clearly turned to be wrong. I distinctly remember being
> surprised at that time by the announcement of 3.12's first-class
> module, and thinking when Xavier Leroy mentioned GADTs -- at the 2008
> meeting -- that it would just never happen.

Yeah, when they do release something there seems to be allways something
new and shiny added. I also don't so much mind a language that remains
static. Means existing code does not break. Ocaml has been verry good in
this and only added to the language without breaking compatibility (much).

> (3) is currently being worked on by different people. The OCaml
> Batteries Included project as an ambitious goal to provide a
> community-built "distribution" of OCaml software in a coherent whole
> (the idea was later taken, and impressively performed, by the "Haskell
> Platform" effort). It has since restrained it ambitions to providing a
> superset of the libraries distributed with the compiler, as a wider
> "standard library". Jane Street Core's library similarly aims to
> provide a "bigger standard library", with in particular an impressive
> offering regarding the pervasive cross-module aspects such as
> marshalling / unmarshalling data and similar datatype-generic
> concerns.
>   http://batteries.forge.ocamlcore.org/
>   http://ocaml.janestreet.com/?q=node/13
>
> Using, contributing to or talking about those projects would also help
> OCaml not to "loose ground". I won't make any judgement on whether a
> more complete library is more or less useful that a change to the
> compiler toolchain, and it certainly is a different kind of work prone
> to interest different peoples. But it is also an important aspect of
> the OCaml ecosystem.
> I have irregularly contributed to the Batteries project, and I know
> for sure that the project is willing to accept any help on things to
> improve (in particular unit testing and documentation). Even, or
> especially, small one-shot contributions can help : three unit tests
> for a given function, a new tiny auxiliary function in such module, a
> bunch of typo fixes for the documentation...

As you say this is being worked on and this can be easily be worked on
outside of the compiler. This is just add-ons that need little to no
coordination with the ocaml core team.

Over the years many extra modules have been written and the OCaml
Batteries Included project has taken up the job of integrating those
modules with each other into a cohesive collection. Cudos to them, they
are doing a great work.

I think what we need for the ocaml core is exactly something like
Batteries but at a lower level. A group of people that will work
together to grab the little bug fixes and feature from various ocaml
forks and provide a single point of communication between both the core
team and forks as well as between forks itself. Even if it just improves
the communication between forks and maybe manages to merge a few of them
it will be a big win.

As a second example, not ocaml related as such, of what we need maybe
look at glibc. The glibc upstream has been slow and difficult to accept
patches. So lots of linux distribution had to maintain their own patches
for a long time, esspecially for not x86 architectures, and bugfixes
where not shared between distribution as a result. So a bunch of people
got together and create eglibc. Several distributions now use eglibc and
bugfixes flow from distributions to eglibc and from there to glibc
upstream and back to other distriutions. Now bugfixes spread quickly
between the distributions.

MfG
        Goswin