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 pBB94FNw009075 for ; Sun, 11 Dec 2011 10:04:15 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmsDAJ1x5E6K54gDgWdsb2JhbABDhDdQozmCPiIBARYmJYFyAQEFDBdVARAJAhoCBRYLAgIJAwIBAgFFBg0BBwIQh3ajT5BfgTSJI4EWBJRxhUuMXQ X-IronPort-AV: E=Sophos;i="4.71,334,1320620400"; d="scan'208";a="134891689" Received: from rouge.crans.org ([138.231.136.3]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 11 Dec 2011 10:04:10 +0100 Received: from localhost (localhost.crans.org [127.0.0.1]) by rouge.crans.org (Postfix) with ESMTP id B871C85CF; Sun, 11 Dec 2011 10:04:09 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at crans.org Received: from rouge.crans.org ([10.231.136.3]) by localhost (rouge.crans.org [10.231.136.3]) (amavisd-new, port 10024) with LMTP id WvGAR5BfgYWs; Sun, 11 Dec 2011 10:04:09 +0100 (CET) Received: from [192.168.39.1] (fbx.up7.fr [81.56.96.177]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by rouge.crans.org (Postfix) with ESMTPSA id 6477C85C0; Sun, 11 Dec 2011 10:04:09 +0100 (CET) Message-ID: <4EE47208.1090506@glondu.net> Date: Sun, 11 Dec 2011 10:04:08 +0100 From: =?UTF-8?B?U3TDqXBoYW5lIEdsb25kdQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Icedove/3.1.16 MIME-Version: 1.0 To: Gabriel Scherer CC: Wojciech Meyer , =?UTF-8?B?SsOpcsOpbWll?= =?UTF-8?B?IERpbWlubw==?= , caml-list@inria.fr, Xavier Leroy References: <55531934-37A5-4CC5-AB67-20CE4CCE8269@googlemail.com> <4EE37070.4010702@inria.fr> <1323541702.32136.8.camel@aurora> <1323550544.32136.19.camel@aurora> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=49881AD3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id pBB94FNw009075 Subject: Re: [Caml-list] Camlp4/p5 type reflection [was: OCaml maintenance status / community fork (again)] Le 11/12/2011 00:34, Gabriel Scherer a écrit : > The original Camlp4 tool was mostly developped by Daniel de > Rauglaudre. > [...] > (I'm thinking of > eg. Martin Jambon, which had extensive Camlp4 extensions, and the Coq > team which has user-defined notations using Camlp4 and, huh, I really > don't want to know the details); basically they didn't upgrade to > 3.10 -- instead of porting the extensions, as was originally hoped. > [...] > Daniel, which apparently did not agree with some of the changes made, > relatively suddenly restarted developpment of "his" branch of Camlp4, > taken from the old sources, before refactoring. This was done as > a separate project, outside the OCaml distribution (apparently Daniel > and the OCaml team prefer not to work together). > [...] > Camlp4 is a piece of devil beauty. It does incredibly clever things, > and is incredibly complex inside: Daniel is clearly a remarkable > hacker, but his code is not easy to understand. I know that > maintaining the whole thing is very hard; and that is the reason why > Camlp4 tends to have problems to bump from one version to another, > when non-neglectible syntaxic changes are made to the language. > [...] > (And I'm not sure it's a good idea to move Camlp4 out of the > distribution as long as we don't have a viable alternative proposal > and some users have started moving to it. Camlp4 will still need to be > supported by someone anyway, and it needs to evolve in lockstep with > OCaml language changes.) Coq has been adapted to work with both camlp4 and camlp5. In my experience, Daniel has been much more responsive on camlp5 matters than the OCaml team on camlp4 matters. And Xavier's mail suggests that camlp4 is a maintenance burden for the OCaml team. Why is it such a bad idea to drop camlp4 out of the distribution, and just let camlp5 live? My feeling is that people using camlp5 care about it, but people using camlp4 do so just because it's in the official distribution and wouldn't care switching to camlp5 (or stop using this kind of syntax extension) if camlp4 was officially deprecated in favor of camlp5. At worst, someone will start maintaining camlp4 independently. Daniel already maintains and develops camlp5. I guess Jérémie would also volunteer to join him (but he already offered to maintain camlp4 independently). In Debian, there are currently 49 packages depending on camlp4, and 7 depending on camlp5. That also increases incentive / possible help for maintaining it. Cheers, -- Stéphane