Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005665OCamlCamlp4public2012-06-28 17:512012-07-05 17:26
Reporterhongboz 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityhave not tried
StatusacknowledgedResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0005665: support deep antiquotation
Descriptioncurrently 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.
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0007623)
gasche (developer)
2012-06-28 22:52

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.
(0007624)
hongboz (developer)
2012-06-29 15:04

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
(0007625)
hongboz (developer)
2012-06-29 21:06

another instance for ocaml is Camlp4QuotaionCommon.ml for antiquot_expander.
If well designed, there should be no Constructors
(0007640)
hongboz (developer)
2012-07-05 04:13

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.
(0007641)
hongboz (developer)
2012-07-05 04:25

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
(0007643)
hongboz (developer)
2012-07-05 17:26

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

- Issue History
Date Modified Username Field Change
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
Powered by Mantis Bugtracker