|Anonymous | Login | Signup for a new account||2014-09-19 05:48 CEST|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005665||OCaml||Camlp4||public||2012-06-28 17:51||2012-07-05 17:26|
|Priority||normal||Severity||feature||Reproducibility||have not tried|
|Target Version||Fixed in Version|
|Summary||0005665: support deep antiquotation|
|Description||currently camlp4 does not support nested antiquotations very well. This's common idiom when you write complex macros, however.|
(I used , to denote antiquotations below)
For example <:expr< <:expr< ,,(f x)) >> >>
We can not do this in camlp4 simply because we use double $$ to denote antiquotations. We may consider some design to make this feature in.
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.
|Tags||No tags attached.|
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.
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
another instance for ocaml is Camlp4QuotaionCommon.ml for antiquot_expander.
If well designed, there should be no Constructors
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 a>> (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.
|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|
|Sorry that I forget to add the link https://bitbucket.org/HongboZhang/ocaml [^]|
|2012-06-28 17:51||hongboz||New Issue|
|2012-06-28 22:52||gasche||Note Added: 0007623|
|2012-06-29 15:04||hongboz||Note Added: 0007624|
|2012-06-29 21:06||hongboz||Note Added: 0007625|
|2012-07-04 16:38||doligez||Severity||minor => feature|
|2012-07-04 16:38||doligez||Status||new => acknowledged|
|2012-07-05 04:13||hongboz||Note Added: 0007640|
|2012-07-05 04:25||hongboz||Note Added: 0007641|
|2012-07-05 17:26||hongboz||Note Added: 0007643|
|Copyright © 2000 - 2011 MantisBT Group|