From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id pBBBd9o5013588 for ; Sun, 11 Dec 2011 12:39:09 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYAAMyU5E5KfVIqimdsb2JhbABDqnQIIgEBAQoJDQcSBiGBcgEBAQMBDAYCLAEbHQEDAQsGBQsDCi4iAREBBQEcBhMUBQmHZpgzCotkgmuDdz2IcQIFDIthBJRxjXE9g3o X-IronPort-AV: E=Sophos;i="4.71,335,1320620400"; d="scan'208";a="122908227" Received: from mail-ww0-f42.google.com ([74.125.82.42]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 11 Dec 2011 12:39:03 +0100 Received: by wgbds13 with SMTP id ds13so6496130wgb.3 for ; Sun, 11 Dec 2011 03:39:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=Og4a0BD4PrKd4nT41kIsJolwx+3sMEUZ8zg0PYoROgA=; b=VhCK0/ks5TOy98FzVWJm82667WS2BhDVBpCq5c1oyjtNdNwNlXfoQVrqHT5GREKwnC oOvSZG168/MV3+2IopIKQcyoZsYdsZ8jvThw4gbiK8qIcdctL4JTwIF1R50mgg8Ovmgb AwIDIp0P/jDdHTmm+1AST80okHlrNf5qjdePA= Received: by 10.180.3.37 with SMTP id 5mr17839584wiz.43.1323603543222; Sun, 11 Dec 2011 03:39:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.43.4 with HTTP; Sun, 11 Dec 2011 03:38:42 -0800 (PST) In-Reply-To: <1323602633.6079.49.camel@samsung> References: <55531934-37A5-4CC5-AB67-20CE4CCE8269@googlemail.com> <4EE37070.4010702@inria.fr> <1323541702.32136.8.camel@aurora> <1323550544.32136.19.camel@aurora> <4EE47208.1090506@glondu.net> <1323602633.6079.49.camel@samsung> From: Gabriel Scherer Date: Sun, 11 Dec 2011 12:38:42 +0100 Message-ID: To: Gerd Stolpmann Cc: caml-list@inria.fr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id pBBBd9o5013588 Subject: Re: [Caml-list] Camlp4/p5 type reflection [was: OCaml maintenance status / community fork (again)] Gerd, you are summing up in a few paragraphs what I tried to say in a few pages. There are other parts of Camlp4 that I would also welcome: - the OCaml quotation parsers that reads quoted OCaml expression (and patterns) and translate them to their ASTs (as an OCaml expression); this makes generating OCaml code easy - controlled extension points such as 'type-conv' and 'deriving', hopefully generalized to most AST nodes; this goes in the direction of Alain's annotation proposal > There could be still camlp4 or p5 as a separate add-on, > but it will be a second-class citizen, and it would be clear that it is > a bit behind with the newest syntactical features. It's not a big problem if the second-class extensions have trouble processing and producing pieces of OCaml AST using the newest syntactical features (eg. the OCaml quotations don't have sugar for them). But it's a problem if they simply can't be run on files using those features, forcing their users to keep older versions of OCaml. It's not a *new* problem as it already appears at version transitions, but it also won't go away as long as people use a preprocessor that insists on understanding the whole AST, whether those tools are first- or second-class. On Sun, Dec 11, 2011 at 12:23 PM, Gerd Stolpmann wrote: > Many people are still frustrated with the camlp4/p5 situation. IMHO, we > should give up on camlp4 inside the distribution, and only implement a > few of its features in the regular parser: > > - Antiquotation syntax (i.e. << >> expressions) because this makes it >  very easy to incorporate foreign syntax elements. Of course, we >  would also need the ability to recursively invoke the ocaml parser >  for parts of the antiquoted expression (this would also open the >  door for transformations of the AST). > > - A simple macro language (ifdef at least), for the cases antiquotations >  would be too complex. > > That means we would give up on arbitrary syntax extensions in the core > distribution. There could be still camlp4 or p5 as a separate add-on, > but it will be a second-class citizen, and it would be clear that it is > a bit behind with the newest syntactical features. Also, it could be > developed outside the core team. > > Gerd > > > Am Sonntag, den 11.12.2011, 11:29 +0100 schrieb Gabriel Scherer: >> > 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? >> >> First of all, I don't have a strong opinion here: I just voiced >> doubt. My reasoning for going so goes along two lines of argument: >> >> 1. I'm not exactly sure how Camlp4 being in or out of the distribution >>    will change the maintainance burden. The main maintainance >>    difficulty with camlp{4,5} is that it needs to evolve its own >>    parser in parallel with the 'official' one (that's by design), with >>    changes to the language syntax. You need to change Camlp{4,5} when >>    Ocaml 3.N+1 introduces a new syntax, or it won't be usable on OCaml >>    3.N+1 code. >> >>    There are already users relying on Camlp{4,5}, and those user >>    generally wish to use the new, exciting features of the next >>    version. If they can't, they will complex, regardless of whether >>    their preprocessor is in or out the distribution. That means that >>    when the OCaml team is about to release a new version with >>    syntactic changes, they have to worry about the preprocessor >>    anyway, or make users unhappy. >> >>    So there is a "preprocessor burden" on the OCaml team, independently >>    of where the code is maintained and located. If the change means >>    "make it easier to distribute camlp4 fixes without bumping OCaml's >>    version number", why not. If it means "now we won't care about >>    Camlp4 state before releasing a new versions", this may mean >>    a degradation in the life of Camlp4 users. I doubt that's the idea. >> >>    Being in or out the distribution also wouldn't change much, I think, >>    the possibility of external contributions. In my experience Nicolas >>    Pouillard and now Xavier Clerc have a good track record of >>    integrating external contributions (I have sent one or two bugfixes >>    on the tracker), and I'm confident they would be able to work with >>    Jérémie Dimino if he wished to contribute to camlp4's evolution more >>    frequently. >> >> 2. I suppose -- purely personal guess -- the intention being the >>    consortium's suggestion is to try to move away slowly from >>    Camlp{4,5}, towards alternatives such as Alain Frisch's >>    "annotations" proposal. As I said previously, I would personally >>    welcome such a move, but I don't see said alternatives released >>    yet. I haven't had the opportunity to play with alternate tools, >>    have an idea of how a transition would work out, see if the >>    documentation is reasonably complete, etc. >> >>    It would make more sense, in my opinion, to downplay camlp{4,5} >>    *once* we have played with alternatives and are confident that they >>    are mature enough to make a transition. >> >>    Please also remember that the consortium members represent >>    relatively large, well-educated, experienced players in the OCaml >>    community. It probably wouldn't bother them much if, say, >>    ocamlbuild, ocamldoc, or ocamldbg where taken out of the official >>    distribution. They have important tooling in place and would adapt >>    relatively easily. The end user or OCaml beginner may not adapt to >>    such changes that easily. Now this is a matter where distributions, >>    such as Debian, can be of great help, by providing "complete" >>    packages regardless of what is or isn't in the official >>    distribution. However, I have handled just enough users reports >>    wondering why they didn't have "camlp4o" available, or >>    graphics.cma, or whatever, to know that this can also be a barrier >>    to use and adoption. >> >> >> Again, no strong opinion. I will welcome any change that strenghten >> the OCaml language. If you think distributing camlp4 out of the >> distribution would ease the live of OCaml developpers and maintainers, >> at no cost to the users, nor complicating the distribution side, then >> all is good. I just feel that it may be a bit too soon. >> >> >> On Sun, Dec 11, 2011 at 10:04 AM, Stéphane Glondu wrote: >> > 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 >> > >> >> > >