[wg-camlp4] Meta Programming from the view of the implementaion

[Hongbo Zhang]

On Thu, Jan 31, 2013 at 7:54 AM, Alain Frisch <alain.frisch at lexifi.com>wrote:

> On 01/30/2013 02:18 PM, Hongbo Zhang wrote:
>
>> Ast Rewriter is *bad *for arbitrary code generation, its neat case is
>> something like bisect.
>>
>
> 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?

This could have a even better solution (not global Ast rewriting) in Fan
without introducing any global Ast rewriting.
{:ocaml|
type t = A of int
|}
{:derive|(Print,Eq,Meata,...)|}


>
>  And Ast Rewriter is not composable at  all,
>> suppose you have two AST Rewriters A,B ,there are no guarantee that  A.B
>> == B.A, it just gives you an illusion that it works, probably it
>> silently fails.
>>
>
> 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.
>
> 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?

> 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.
>
> We have provided purely functional grammars API which helps a lot to limit
the scope of the syntax extension*, if people don't like it, just not
expose it, or write another frontend with fixed grammar.* But we do have a
lot of things that Ast Rewriter does not provide, quasiquotation(which I
think is a *fundamental* 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

>
>      3. How do you implement the expander?  Somehow, you need to parse
>>     the content of the quotation (stored as a string in the AST), which
>>     involves non trivial stuff, like a parser being able to parse OCaml
>>     code mixed with something else.  Personally, I don't know how to
>>     implement the quotation expander with the parsing technologies I'm
>>     familiar with.
>>
>> when you design your DSL, the left part is pretty easy to parse, when
>> you see the delimiter "->", invoking an existing parser.
>>
>
> So you need to:
>
>  - Write a custom parser for left parts (regexps), which stops at "->".
> To write this parser, you need to use ocamlyacc, menhir, or another tool.
> (And probably plug the official OCaml lexer?)
>  - Call the official(?) OCaml parser on its "expr" entry and hope that it
> stops exactly when it encounters the next "|" (does this really work?).
>  - 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.
>
> This is *already implemented in Fan within tens of lines of code,* 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)

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


-- 
-- Regards, Hongbo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/wg-camlp4/attachments/20130131/ca4fee97/attachment-0001.html>