caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Gerd Stolpmann <info@gerd-stolpmann.de>
To: bob zhang <bobzhang1988@gmail.com>
Cc: Alain Frisch <alain@frisch.fr>, caml-list@inria.fr
Subject: Re: [Caml-list] Re: Syntax extensions without Camlp4
Date: Thu, 31 May 2012 19:28:59 +0200	[thread overview]
Message-ID: <1338485339.17140.120.camel@thinkpad> (raw)
In-Reply-To: <CANcqPu6w5anbHdw7Es3tk0dd-pFVzQ43yU0OPEPxqFi-hrvM7Q@mail.gmail.com>

Am Donnerstag, den 31.05.2012, 12:01 -0400 schrieb bob zhang:
> 
> 
> On Thu, May 31, 2012 at 8:59 AM, Alain Frisch <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, 
>    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.

> 
> 
>         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.

>          - 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

-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
Creator of GODI and camlcity.org.
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
*** Searching for new projects! Need consulting for system
*** programming in Ocaml? Gerd Stolpmann can help you.
------------------------------------------------------------


  reply	other threads:[~2012-05-31 17:28 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-27 15:06 [Caml-list] " Alexandre Pilkiewicz
2012-05-27 16:53 ` [Caml-list] " Hongbo Zhang
2012-05-27 18:04   ` Daniel Bünzli
2012-05-27 18:18     ` Hongbo Zhang
2012-05-27 19:01       ` Daniel Bünzli
2012-05-27 22:43         ` Wojciech Meyer
2012-05-28  9:35           ` Daniel Bünzli
2012-05-28  9:59             ` Gabriel Scherer
2012-05-30 14:45               ` Hongbo Zhang
2012-05-28 11:17             ` Wojciech Meyer
2012-05-28 15:52             ` Jeffrey Scofield
2012-05-27 18:19     ` Hongbo Zhang
2012-05-28  8:17     ` Paolo Donadeo
2012-05-30 12:41   ` Alain Frisch
2012-05-30 13:18     ` Markus Mottl
2012-05-30 13:37     ` Dan Bensen
2012-05-30 14:16       ` Hongbo Zhang
2012-05-30 14:23         ` Paolo Donadeo
     [not found]           ` <20120531081913.GA26742@securactive.lan>
2012-05-31 12:26             ` Paolo Donadeo
2012-05-31 12:38               ` Anil Madhavapeddy
2012-05-31 12:40                 ` Anil Madhavapeddy
2012-05-31 12:46                   ` Yaron Minsky
2012-05-31 12:47                   ` Gabriel Scherer
2012-05-31 22:08                 ` Paolo Donadeo
2012-05-30 14:14     ` Hongbo Zhang
2012-05-31 12:59       ` Alain Frisch
2012-05-31 13:21         ` Dmitry Grebeniuk
2012-05-31 14:30           ` Daniel Bünzli
2012-05-31 16:01         ` bob zhang
2012-05-31 17:28           ` Gerd Stolpmann [this message]
2012-05-31 18:03             ` Wojciech Meyer
2012-05-31 18:32               ` Gerd Stolpmann
2012-05-31 18:32             ` Hongbo Zhang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1338485339.17140.120.camel@thinkpad \
    --to=info@gerd-stolpmann.de \
    --cc=alain@frisch.fr \
    --cc=bobzhang1988@gmail.com \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).