From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by sympa.inria.fr (Postfix) with ESMTPS id 0B92C7ED26 for ; Wed, 30 May 2012 16:14:49 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoBAFYqxk/RVdy2mGdsb2JhbABEgkWIY6hdCCIBAQEBAQgJDQcUJ4IXAQEBBBICExkBGxQJAQMMBgULDQkMGQ8CEhEBBQEcBg0BBwEBFweHWgEDC5pOCQOMK4JwhQcKGScNV4hxAQUMinmCIIMiA5UYjhY+hBs X-IronPort-AV: E=Sophos;i="4.75,685,1330902000"; d="scan'208,217";a="160590540" Received: from mail-vc0-f182.google.com ([209.85.220.182]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 30 May 2012 16:14:48 +0200 Received: by vcbfy7 with SMTP id fy7so4704771vcb.27 for ; Wed, 30 May 2012 07:14:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=OXCe9Z/3pp4fff52WBJTZVuO3VL/8heBaa5gAMyRNAE=; b=pZlqTbPrcU0JcKocNXvUqRM1FwnaNgMKuyHAkwl8t9FfKuHWShXu3Q0q5OnjMfU1b0 RKEKzQqDF+5Z4relQInK8F9qy83tUynQr/bd+sHbBv5KtG942T3KhiAM3sELgCtMyLLJ 7+HfF5bW6FUDM8+aqD5zdxMbS+R0WZwJFHsbI1wEXCuocvxuXlpiAV/wriKpdsIVuw9L s2+ydJXSbQv9ag+H7oHrWPUg40imLyV+JxjxZtr1XgLjUZYpQKMKszgX5HShdCYOgiAg 6gN9UcfdzpViJHX9dub2UZ9wha0VD1Pp32avvCknaFKgxzDJep2XG+Go469pbKeGF4Oi xbNw== Received: by 10.52.21.229 with SMTP id y5mr14417875vde.68.1338387286483; Wed, 30 May 2012 07:14:46 -0700 (PDT) Received: from vpl317.wlan.library.upenn.edu (vpl317.wlan.library.upenn.edu. [130.91.141.62]) by mx.google.com with ESMTPS id j16sm29839810vdt.9.2012.05.30.07.14.44 (version=SSLv3 cipher=OTHER); Wed, 30 May 2012 07:14:45 -0700 (PDT) Message-ID: <4FC62B53.20504@gmail.com> Date: Wed, 30 May 2012 10:14:43 -0400 From: Hongbo Zhang User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Alain Frisch CC: caml-list@inria.fr References: <4FC61595.6070009@frisch.fr> In-Reply-To: <4FC61595.6070009@frisch.fr> Content-Type: multipart/alternative; boundary="------------050107070901040507040200" Subject: Re: [Caml-list] Re: Syntax extensions without Camlp4 This is a multi-part message in MIME format. --------------050107070901040507040200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 5/30/12 8:41 AM, Alain Frisch wrote: Hi Alain, Thanks for your message. I am building a framework on top of camlp4, which provides those features you mentioned in the post in a flexible way. It needs to be polished. So far, writing generic plugins is really easy. (generic printing, comparison, lift filter, etc , each about 20 lines). The conclusion below is based on my observation and experiences. Feel free to correct me if I am wrong. 1. Why camlp4 is buggy? The main buggy part is its parsing technology. So is its parsing technology a bad idea? No, it's really convenient for rapid ad-hoc prototyping, suppose you don't need write a lexer, and its parser simply works in the toplevel, the parser itself it really shorter even compared with menhir, if you refactor your parser part. The main buggy part lies in camlp4of, which is not tested at all. it's easy to test camlp4o, camlp4rf. There's large code base written both in camlp4o and camlp4rf. So in my opinion, we should just *drop camlp4of*, unless it's really heavily tested. *camlp4rf* is a good syntax, in my experience, it just took me one day to get used to, and I wrote my daily caml code in revised syntax. It's not hard to learn. It's much easier compared with the complexity of camlp4ast or ocamlast. So, IMHO, we should just advise camlp4 developers to use revised syntax. It would be nice if Daniel would write some articles how internal parser mechanism works. Revised syntax just catch up with the trunk, it should not be exactly the same, this gives the caml develop team enough freedom to introducing new constructs(monad support, etc) 2. About the proposal. There are mainly 2 pieces. About the hook Parsetree.structure->Parsetree. structure, given that camlp4 already imports Parsetree, it's really trivial to add another hook after camlp4astdump2ocamlast. The other piece about introducing attribute grammar, whcich is orthogonal to camlp4, IMHO. It's still nontrivial to write a robust Parsetree.structure -> Parsetree.structure, it would be nice if we could provide a quotation syntax for Parsetree.types. I would contribute if there was some funding support. 3. Extending the syntax. It is really nice to extend your syntax for ad-hoc hacking. Your nice software ulex, and bitstring is a good example. It could be even better to just introduce a new quotation for robustness. But I am against mutating syntax for personal taste. (try finally, monad syntax), those improvement should be in the trunk. Many Thanks > On 05/27/2012 06:53 PM, Hongbo Zhang wrote: >> Well, I don't think it's good to downplay camlp4. The problem is we need >> more documentation and more tests. > > (The new) Camlp4 has been here for several years. Documentation and > tests are still lagging behind. Nevertheless, it burns a > non-negligible fraction of the total resource spent by maintainers on > OCaml (fixing bugs, struggling with camlp4 to take new language > features into account). > > In addition, there is a growing consensus that the most common uses of > camlp4 (such as code generation driven by type declaration) might be > based on a much simpler approach, and this would actually have > advantages for the end-users (like not changing the concrete syntax) > and for developers (much less information to grasp in order to write > such an extension). > > Coq is one of the few examples of a big project that relies on other > aspects of camlp4 (e.g. its parsing framework with extensible > grammars). As far as I know, it also still works with camlp5, which > is actively maintained, and I don't believe the Coq guys enjoy so much > maintaining support for both camlp4 and campl5. > > All that considered, and this is only a personal opinion: I don't see > compelling arguments to continue investing efforts in camlp4 itself > (at least, for the core OCaml team) and I believe it is a good time to > start considering a (medium-term) future of OCaml without camlp4. Of > course, alternative solutions need to be developed and streamlined > before killing camlp4 is even considered. > > > Alain --------------050107070901040507040200 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 5/30/12 8:41 AM, Alain Frisch wrote:
Hi Alain,
   Thanks for your message.
   I am building a framework on top of camlp4, which provides those features you mentioned in the post in a flexible way. It needs to be polished. So far, writing generic plugins is really easy. (generic printing, comparison, lift filter, etc , each about 20 lines).
   The conclusion below is based on my observation and experiences. Feel free to correct me if I am wrong.

   1. Why camlp4 is buggy?
   The main buggy part is its parsing technology.  So is its parsing technology a bad idea? No, it's really convenient for rapid ad-hoc prototyping, suppose you don't need write a lexer, and its parser simply works in the toplevel, the parser itself it really shorter even compared with menhir, if you refactor your parser part.
   The main buggy part lies in camlp4of, which is not tested at all. it's easy to test camlp4o, camlp4rf. There's large code base written both in camlp4o and camlp4rf. So in my opinion, we should just *drop camlp4of*, unless it's really heavily tested. *camlp4rf* is a good syntax, in my experience, it just took me one day to get used to, and I wrote my daily caml code in revised syntax. It's not hard to learn. It's much easier compared with the complexity of camlp4ast or ocamlast. So, IMHO, we should just advise camlp4 developers to use revised syntax. It would be nice if Daniel would write some articles how internal parser mechanism works. Revised syntax just catch up with the trunk, it should not be exactly the same, this gives the caml develop team enough freedom to introducing new constructs(monad support, etc)

  2. About the proposal.
    There are mainly 2 pieces. About the hook  Parsetree.structure -> Parsetree. structure, given that camlp4 already imports Parsetree, it's really trivial to
add another hook after camlp4astdump2ocamlast.
    The other piece about introducing attribute grammar, whcich is orthogonal to camlp4, IMHO.
    It's still nontrivial to write a robust Parsetree.structure -> Parsetree.structure,  it would be nice if we could provide a quotation syntax for Parsetree.types. I would contribute if there was some funding support.
 
 3. Extending the syntax.
    It is really nice to extend your syntax for ad-hoc hacking. Your nice software ulex, and bitstring is a good example. It could be even better to just introduce a new quotation for robustness.

    But I am against mutating syntax for personal taste. (try finally, monad syntax), those improvement should be in the trunk.

Many Thanks
On 05/27/2012 06:53 PM, Hongbo Zhang wrote:
Well, I don't think it's good to downplay camlp4. The problem is we need
more documentation and more tests.

(The new) Camlp4 has been here for several years.  Documentation and tests are still lagging behind.  Nevertheless, it burns a non-negligible fraction of the total resource spent by maintainers on OCaml (fixing bugs, struggling with camlp4 to take new language features into account).

In addition, there is a growing consensus that the most common uses of camlp4 (such as code generation driven by type declaration) might be based on a much simpler approach, and this would actually have advantages for the end-users (like not changing the concrete syntax)
and for developers (much less information to grasp in order to write such an extension).

Coq is one of the few examples of a big project that relies on other aspects of camlp4 (e.g. its parsing framework with extensible grammars).  As far as I know, it also still works with camlp5, which is actively maintained, and I don't believe the Coq guys enjoy so much maintaining support for both camlp4 and campl5.

All that considered, and this is only a personal opinion: I don't see compelling arguments to continue investing efforts in camlp4 itself (at least, for the core OCaml team) and I believe it is a good time to start considering a (medium-term) future of OCaml without camlp4.  Of course, alternative solutions need to be developed and streamlined before killing camlp4 is even considered.


Alain

--------------050107070901040507040200--