Comment author: @gasche

Do you have real examples of reasonable "complex macros" that require nested antiquotations? While I have of course often seen nestings such as <:expr< ... $ ... << foo >> ... $ ... >> (they work correctly, including, I think, if foo has antiquotations), I have never seen or used <:expr< ... << ... >> ... >> myself. I think real examples could help make your point.

Does people in INRIA consider switching parsing engine of camlp4 to dypgen? I have read it carefully, and found dypgen is the right tool as a parsing engine for camlp4.

As far as I know, there is no ongoing plan in this direction, and I wouldn't bet on it if I were you. What's the point of replacing code that work with a full reimplementation that will certainly break existing code, need some time to debug, etc.? Camlp4 already has an implementation of dynamic grammars, I don't see the reason to switch to dypgen that would offset the associated costs.

Comment author: @bobzhang

check out the book "http://letoverlambda.com/". many useful macros in lisp involved deep antiquotation. One example in OCaml is the file
camlp4/Camlp4Filters/Camlp4MetaGenerator.ml which hard code the constructor name even though there is quasiquotation support for every ast node.

Dypgen GLR parser is more fit for syntax extension compared with LL(*) parser(and some hacks to merge some rules)camlp4 keeps stagnant for a long time without new features added. IMHO, camlp4 is not a complex beast, just some wrong designs need to be fixed instead of keeping patching. However, since 4.00, compiler-lib is installed officially, there's no technical reasons to distribute it with ocaml, is it possible to distribute it separately to attract more community contributions? Sorry If I made some mistakes

Comment author: @bobzhang

another instance for ocaml is Camlp4QuotaionCommon.ml for antiquot_expander.
If well designed, there should be no Constructors

Comment author: @bobzhang

I made a change which supports deep antiquotation.

now you want to generate macros <:patt< .$uid:str$. >>, you only
need to write <:expr< <:patt< .$uid: .$str$. $. >> >> without hard code any constructor.
That's to say, it now supports arbitrary depth quotation, antiquotation. With that, the expressivity is improved a lot, you can write macros which generate macros much easier.
The change is minimal, only tiny bits of Lexer.mll

The second change I made is the quotation delimiters are changed to
<< >>
or <> (a is a arbitrary symbol char). now you can quote c-style language without changing >> to >>.

The third change I made is now it improves default_quotatoion syntax, it needs a paramerter of position. That's is to say you can specify default quotation expander in different positions. (pattern position, expr position). The immediate benefit is it can save you typing, and improves read-ability. Another benefit is you can compose with other macros INCLUDE which shares the code only if their concrete syntax is the same. This is great, for example, most pattern Ast Nodes are the same as expr Ast Nodes

If people in INRIA are interested in the change, I would be happy to help.

Comment author: @bobzhang

To add, only the first change breaks in-compatibility, the following two changes does not break the compatibility. But without arbitrary deep quotation support, it's too difficult to write macros generate macros

Comment author: @bobzhang

Sorry that I forget to add the link https://bitbucket.org/HongboZhang/ocaml

Comment author: @diml

Camlp4 is now a separate project. Please re-open a ticket on github [1] if you are still interested in seeing the original issue fixed.

[1] https://github.com/ocaml/camlp4/issues