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 678EE7ED26 for ; Thu, 31 May 2012 20:32:07 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwCAO24x0/RVdy2mGdsb2JhbABEhU2qVINrCCIBAQEBAQgJDQcUJ4IYAQEBBBICDwQRCAEbHAIDDAYFCwMKAgIFFgsCAgkDAgECARERAQUBHAYBDAYCAQEQDodaAQMLmmsJA4tSUIJwhE4KGScNV4hxAQUMgReJbhSEIIESA5UYjhY+hBuBOg X-IronPort-AV: E=Sophos;i="4.75,693,1330902000"; d="scan'208";a="146084069" Received: from mail-vc0-f182.google.com ([209.85.220.182]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 31 May 2012 20:32:06 +0200 Received: by vcbfy7 with SMTP id fy7so1260985vcb.27 for ; Thu, 31 May 2012 11:32:05 -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:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=irdIjRjen71KoDTrTKit+XjaBn8OjNneSbgXem2yrH0=; b=hEXWKAEcpVgiBpRafWEtlvxPhnRUIRrRlqQztkS2CSwCSiuoWeHnjijoJN0dM7TgSM IKEHJwCSf+ZLY9CGhkbBjtmsSRu+CVjVmSuve8cXTSKtfUDXaPD/hUobIWLI9SAvBTt+ TqrYPve5nmAzr9otyGB+zKLkSSZPM+fQyjuonj3GQmJha5ae0DQaWD6dKp31LsmRoB3Q R1REEcCKxOjBhJyq4s8VleO4Ri7Nkgvr6MrVyeuZB5GLsVbj6OKSyxHfE6h6dIOBZF2F vmOApFF1CcreplChBHAi+skliLggEv1uHl9n5gKaTpot/ac+wmZi5g0koZnih3mhTNsC 94rg== Received: by 10.52.70.116 with SMTP id l20mr2650933vdu.19.1338489125117; Thu, 31 May 2012 11:32:05 -0700 (PDT) Received: from vpl217.wlan.library.upenn.edu (vpl217.wlan.library.upenn.edu. [130.91.140.218]) by mx.google.com with ESMTPS id d20sm6063227vde.20.2012.05.31.11.32.04 (version=SSLv3 cipher=OTHER); Thu, 31 May 2012 11:32:04 -0700 (PDT) Message-ID: <4FC7B923.3030206@gmail.com> Date: Thu, 31 May 2012 14:32:03 -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: Gerd Stolpmann , Caml List References: <4FC61595.6070009@frisch.fr> <4FC62B53.20504@gmail.com> <4FC76B3E.2070509@frisch.fr> <1338485339.17140.120.camel@thinkpad> In-Reply-To: <1338485339.17140.120.camel@thinkpad> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] Re: Syntax extensions without Camlp4 On 5/31/12 1:28 PM, Gerd Stolpmann wrote: > Am Donnerstag, den 31.05.2012, 12:01 -0400 schrieb bob zhang: >> >> 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. > IMHO, there is no point in discussing "revised" (actually, alternate) > syntax. It might be easier to parse, but most programmers are used to > the standard syntax. The problem here is that it is difficult for a > human to switch between two syntaxes. > > That said, I'm for dropping the alternate syntax entirely. It depends. I wrote camlp4 related programs in revised syntax, and normal caml code in original syntax, it may seem awful at first, but once you get used to it, it's really a minor issue compared with waiting for patches for camlp4of. If you look at mantis, most camlp4 related bugs are about camlp4of. Dropping camlp4of will help alleviate the burden a lot >> >> 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) > What's the problem with antiquotations? I imagine that you can simply > call the parser, and it is only a matter of selecting the right entry > point, and passing the tokens down. Campl4 Ast is *quite loose*, and designed this way to tolerate parital Ast, and way more better support for quosiquotation than Template Haskell (etc). This is the last post I commented on this thread. IMHO, we should do some work to improve camlp4, a community to build libraries on top of it to avoid reinventing the wheels instead of dropping existing powerful tools. Many Thanks > >> - 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 guess you are missing Alain's point here. He suggests to use normal > pattern matching directly on parsetrees, as in > > match expr with > | Pexp_ident id -> Pexp_ident (tranform id) > | Pexp_contant c -> Pexp_constant c > | ... > > instead of using camlp4 syntax quotations (no<<...>> stuff for syntax > manipulation anymore). > > Gerd > >> 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