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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by sympa.inria.fr (Postfix) with ESMTPS id C7A447ED27 for ; Thu, 31 May 2012 18:01:39 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMCAGKVx0/RVdgvkGdsb2JhbABEsBmDawgiAQEBAQkJDQcUBCOCGAEBAQMBEgITGQEbHQEDAQsGBQsNLiIBEQEFARwGEyKHWgEDBgWadQkDjCKCcIRdChknDVeIcQEFDIsFFIUyA5UYjhY+hBuBOg X-IronPort-AV: E=Sophos;i="4.75,693,1330902000"; d="scan'208";a="146069363" Received: from mail-qa0-f47.google.com ([209.85.216.47]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 31 May 2012 18:01:39 +0200 Received: by qabg1 with SMTP id g1so3295264qab.6 for ; Thu, 31 May 2012 09:01:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TeRjy1g58RiJJqud137WZFobXYx/4KP0wMnHMUPEz2Y=; b=xs7nIHNnihh0O/4SJgcuWvAuFNSv4b7B9GDfBDlcVK+GoJtgUM7vO9nNN5dzP0DNm3 JPjmSg/Du/AB8SDUgfGzoI+zp4zpz7LbdvCHFL/VS9Fk6RQDNVSjn6urCmRKx2fPlTqz oDi2qXe0tswN/FdzP3ULh9eWxQqfhu2LeRwUXC+CcGdBV4WQNC9nvHqQeF92LlCNkO28 vaCnQ3Gu6d5EXbxZzC6mI+wOFkCwX9/OIt0Z4BbwJ8R81DpoWbDNhauOoJC2oO4aWhT3 492uwx0ugdyFjgqVTxmxahNqI3byLh6ghjtBPNfxGe1qW/cjXhmBCv5NyswHq4ZiZ7Ii sLVw== MIME-Version: 1.0 Received: by 10.60.14.41 with SMTP id m9mr19768757oec.57.1338480097896; Thu, 31 May 2012 09:01:37 -0700 (PDT) Received: by 10.182.144.71 with HTTP; Thu, 31 May 2012 09:01:37 -0700 (PDT) In-Reply-To: <4FC76B3E.2070509@frisch.fr> References: <4FC61595.6070009@frisch.fr> <4FC62B53.20504@gmail.com> <4FC76B3E.2070509@frisch.fr> Date: Thu, 31 May 2012 12:01:37 -0400 Message-ID: From: bob zhang To: Alain Frisch Cc: caml-list@inria.fr Content-Type: multipart/alternative; boundary=e89a8fb1fac0c62b3504c1572ed1 Subject: Re: [Caml-list] Re: Syntax extensions without Camlp4 --e89a8fb1fac0c62b3504c1572ed1 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 31, 2012 at 8:59 AM, Alain Frisch wrote: > 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. > > Hi,Alain, Thanks for your message. Some opinions below: (Feel free to correct if I am wrong) Why do you think it's overly complex? The other part is not complex IMO except the internal mechanism of parsing. There are other benefits of revised syntax. One point is that write an error recover parser is straitforward for revised syntax. And it's more friendly to IDE. 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 simple answer is you can not. (or it's at least not an easy way once you want to support quotation and *antiquotation* *everywhere*. Just take a look at how ugly the Template Haskell program is) > - 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. > > The answer is also you can not. There are some ambiguities that you can not support quotations and antiquotations. Currenty Camlp4 support quotations and antiquotations for revised syntax in all branches except Ast.TyDcl. I agree it would be useful to write a simple quoation expander for Parsetree.structure_item, (with limited antiquotation support) in Camlp4 and add another hook for Parsetree. > - 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 > -- -- Bob --e89a8fb1fac0c62b3504c1572ed1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, May 31, 2012 at 8:59 AM, Alain F= risch <alain@frisch.fr> wrote:
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= .

Hi,Alain,=A0
=A0 =A0Thanks for your message= .
=A0 =A0Some opinions below: (Feel free to correct if I am wrong= )
=A0 =A0Why do you think it's overly complex? The other part= is not complex IMO except the internal mechanism of parsing. There are oth= er benefits of revised syntax. One point is that write an error =A0
recover parser is straitforward for revised syntax. And it's more = friendly to IDE.

Some example of useless complexity:

=A0- A custom notion of AST. Why not simply use the OCaml one? =A0(Extended= with nodes for a new nodes, like quotations.)

The simple answer is you can not. (or it's at lea= st not an easy way once you want to support quotation and *antiquotation* *= everywhere*. Just take a look at how ugly the Template Haskell program is)= =A0
=A0- The use of concrete syntax for manipulating the AST. =A0The developer = needs to understand not only the new AST, but also how it is reflected exac= tly by the concrete syntax quotations (and this is non trivial), and where = anti-quotations are allowed, etc. What's wrong with normal pattern matc= hing and expression building with the standard AST? =A0It might be a little= bit more verbose, but it's so much simpler to understand.

The answer is also you can not. There are some ambigu= ities that you can not support quotations
and antiquotations. Cur= renty Camlp4 support quotations and antiquotations for revised syntax in=A0=
all branches except Ast.TyDcl.

I agree it wou= ld be useful to write a simple quoation expander for Parsetree.structure_it= em, (with limited antiquotation support) in Camlp4 and add another hook for= Parsetree.
=A0- A different syntax (the revised one). =A0I 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 sys= tem.

=A0- A complicated bootstrapping cycle (partly a consequence of the fact th= at Camlp4 is itself written in a custom syntax). =A0That's mostly for O= Caml 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 alre= ady

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. =A0What's im= portant 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 depend= ency on a complex tool for problems which can be solved with something so s= imple.


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 rewr= iting function if you work directly on the "real" AST definition,= rather than a slighlty different one and with a custom syntax. =A0Just for= an example, consider a left-hand side like:

=A0| <:pat< $p1$ | $p2$ | $p3$ >> -> ...

Will it capture both (p1|p2)|p3 and p1|(p2|p3)? =A0Or only one of them?
Another example: controlling precisely locations introduced in the AST frag= ments created with quotations is quite tricky.



Alain



-- -- Bob
--e89a8fb1fac0c62b3504c1572ed1--