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