<br><br><div class="gmail_quote">On Thu, Jan 31, 2013 at 7:54 AM, Alain Frisch <span dir="ltr"><<a href="mailto:alain.frisch@lexifi.com" target="_blank">alain.frisch@lexifi.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 01/30/2013 02:18 PM, Hongbo Zhang wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Ast Rewriter is *bad *for arbitrary code generation, its neat case is<br>
something like bisect.<br>
</blockquote>
<br>
One of the most widely used kind of Camlp4 extensions today is about code generation based on type declarations (plus some annotations), à la type-conv or deriving. This seems to be a perfect match for AST rewriters plus attributes. Don't you agree?</blockquote>
<div>This could have a even better solution (not global Ast rewriting) in Fan without introducing any global Ast rewriting.</div><div>{:ocaml|</div><div>type t = A of int</div><div>|}</div><div>{:derive|(Print,Eq,Meata,...)|}</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And Ast Rewriter is not composable at all,<br>
suppose you have two AST Rewriters A,B ,there are no guarantee that A.B<br>
== B.A, it just gives you an illusion that it works, probably it<br>
silently fails.<br>
</blockquote>
<br></div>
I don't agree. A and B are functions from AST to AST, so there is a very nice notion of composition: the composition of functions. It is true that A.B and B.A don't have the same behavior but at least, I can understand what A.B and B.A will do as soon as I know how A and B behave individually, without having to know anything about their implementation.<br>
<br></blockquote><div>For any nontrivial Ast Rewriter, I totally get lost, maybe I am dumb and you use objects here(ast_mapper) suppose both ast_mapper try to inject some bindings at the beginning, what do you expect here? Besides, there's no reason that Ast Rewriter should be pure, once is impure, how shall I reason the program? </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I know you have projects to provide a cleaner functional API for grammars, but I don't see how modifications of the concrete syntax can be combined, in full generality, in a predictable way. It seems you also have plans to get rid of the ability to modify the concrete syntax. This sounds very reasonable to me.<div class="im">
<br></div></blockquote><div>We have provided purely functional grammars API which helps a lot to limit the scope of the syntax extension<b>, if people don't like it, just not expose it, or write another frontend with fixed grammar.</b> But we do have a lot of things that Ast Rewriter does not provide, quasiquotation(which I think is a <b>fundamental</b> difference from ppx), quotation(delimited DSL), ast rewriter(the same as ppx), type hook(the example I gave before), lexer hook, and lots other stuff</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3. How do you implement the expander? Somehow, you need to parse<br>
the content of the quotation (stored as a string in the AST), which<br>
involves non trivial stuff, like a parser being able to parse OCaml<br>
code mixed with something else. Personally, I don't know how to<br>
implement the quotation expander with the parsing technologies I'm<br>
familiar with.<br>
<br>
when you design your DSL, the left part is pretty easy to parse, when<br>
you see the delimiter "->", invoking an existing parser.<br>
</blockquote>
<br></div>
So you need to:<br>
<br>
- Write a custom parser for left parts (regexps), which stops at "->".<br>
To write this parser, you need to use ocamlyacc, menhir, or another tool. (And probably plug the official OCaml lexer?)<br>
- Call the official(?) OCaml parser on its "expr" entry and hope that it stops exactly when it encounters the next "|" (does this really work?).<br>
- Adapt the locations returned by this parser, or be careful to initialize the lexbuf with locations that match exactly the concrete location of the corresponding part in the original source code.<br>
<br></blockquote><div>This is <b>already implemented in Fan within tens of lines of code,</b> you are much more experienced than me, so I bet you definitely could parse it! (I don't consider tens of lines of code is complex.. ) my taste shows that its notation is much more elegant than sedlex (imho)</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This seems much more complex than the current implementation of sedlex (or a variant of it where regexps would be written with some concrete syntax), for no obvious benefit.<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
Alain<br>
<br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>-- Regards, Hongbo