From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id pB6D9hW7000801 for ; Tue, 6 Dec 2011 14:09:44 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqYBACgT3k7ZSMDdi2dsb2JhbABEp2CCfCIBAQEKCwsHEgUigXIBAQQBOj8FCwshJQ8BBA0bIRMUCodpAga1K4syBJochTCHOw X-IronPort-AV: E=Sophos;i="4.71,305,1320620400"; d="scan'208";a="134158205" Received: from fmmailgate01.web.de ([217.72.192.221]) by mail1-smtp-roc.national.inria.fr with ESMTP; 06 Dec 2011 14:09:38 +0100 Received: from moweb002.kundenserver.de (moweb002.kundenserver.de [172.19.20.108]) by fmmailgate01.web.de (Postfix) with ESMTP id 080A41A425884 for ; Tue, 6 Dec 2011 14:09:38 +0100 (CET) Received: from frosties.localnet ([95.208.118.96]) by smtp.web.de (mrweb002) with ESMTPA (Nemesis) id 0MOB3E-1RSOSj2vcC-005ZkM; Tue, 06 Dec 2011 14:09:37 +0100 Received: from mrvn by frosties.localnet with local (Exim 4.77) (envelope-from ) id 1RXum9-0004vu-7h; Tue, 06 Dec 2011 14:09:37 +0100 From: Goswin von Brederlow To: Gabriel Scherer Cc: Benedikt Meurer , caml users References: <1B0D83BD-1902-4F7C-B3FB-B759122D6AB9@googlemail.com> Date: Tue, 06 Dec 2011 14:09:37 +0100 In-Reply-To: (Gabriel Scherer's message of "Tue, 6 Dec 2011 11:35:55 +0100") Message-ID: <87aa75g832.fsf@frosties.localnet> User-Agent: Gnus/5.110009 (No Gnus v0.9) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Provags-ID: V02:K0:6WrP0IQP8UKMY0ueVf9Im5XymJDNbcW5/gPpo/8YTZo SlSqb5giBbkwOOzvklh4qzrjg3WlAuAyAdq9yuDEpIDTrBtPLS 1tfB/yIhwgZhrpT5esdvVQ6sHxb7R8HSm6/wra2mAnxEGm05m/ BpghsTuQf0pMnriC8cH0LEjN7URdlFa77IgfSdI5MuBHNqDPh3 0C2RHj3K40F0AbBtgbjwA== Subject: Re: [Caml-list] OCaml maintenance status / community fork Gabriel Scherer 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