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 A16E87ED26 for ; Thu, 31 May 2012 14:59:44 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwDAEtqx0/B/BfWlGdsb2JhbABEgx2seymDbAEBAQEJCwkJFAMkghgBAQQBJxFAAQULCw4KCRYPCQMCAQIBRQYNAQcBAYgCCbkCixGFRgOVGIVPjQY X-IronPort-AV: E=Sophos;i="4.75,692,1330902000"; d="scan'208";a="160736703" Received: from msa05.smtpout.orange.fr (HELO msa.smtpout.orange.fr) ([193.252.23.214]) by mail1-smtp-roc.national.inria.fr with ESMTP; 31 May 2012 14:59:44 +0200 Received: from [192.168.1.105] ([86.195.133.194]) by mwinf5d45 with ME id Gczj1j00E4Bp0ce03czjLl; Thu, 31 May 2012 14:59:44 +0200 Message-ID: <4FC76B3E.2070509@frisch.fr> Date: Thu, 31 May 2012 14:59:42 +0200 From: Alain Frisch User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Hongbo Zhang CC: caml-list@inria.fr References: <4FC61595.6070009@frisch.fr> <4FC62B53.20504@gmail.com> In-Reply-To: <4FC62B53.20504@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] Re: Syntax extensions without Camlp4 On 05/30/2012 04:14 PM, Hongbo Zhang wrote: > 1. Why camlp4 is buggy? > The main buggy part is its parsing technology. I don't consider that the main problem with Camlp4 is that it is buggy, but rather that (i) it is overly complex for the benefits it delivers, and (ii) it is actually not such a great idea to change the concrete syntax. Some example of useless complexity: - A custom notion of AST. Why not simply use the OCaml one? (Extended with nodes for a new nodes, like quotations.) - The use of concrete syntax for manipulating the AST. The developer needs to understand not only the new AST, but also how it is reflected exactly by the concrete syntax quotations (and this is non trivial), and where anti-quotations are allowed, etc. What's wrong with normal pattern matching and expression building with the standard AST? It might be a little bit more verbose, but it's so much simpler to understand. - A different syntax (the revised one). I understand the benefits of this new syntax, but it seems kind of crazy to have a "low-level" tool implemented in (and encouraging) a syntax different from the core system. - A complicated bootstrapping cycle (partly a consequence of the fact that Camlp4 is itself written in a custom syntax). That's mostly for OCaml maintainers, but in the past, it has slowed down development in a non-negligible way. > 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. I've absolutely no doubt that Camlp4 can be extended to be at least as powerful as this "Parsetree rewriting" proposal. What's important is that this proposal is so simple that it can be implemented in a few dozens line of code in the core compiler. We should not create a dependency on a complex tool for problems which can be solved with something so simple. > 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 believe the opposite: it's simpler to write a robust AST->AST rewriting function if you work directly on the "real" AST definition, rather than a slighlty different one and with a custom syntax. Just for an example, consider a left-hand side like: | <:pat< $p1$ | $p2$ | $p3$ >> -> ... Will it capture both (p1|p2)|p3 and p1|(p2|p3)? Or only one of them? Another example: controlling precisely locations introduced in the AST fragments created with quotations is quite tricky. Alain