Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support deep antiquotation #5665

Closed
vicuna opened this issue Jun 28, 2012 · 7 comments
Closed

support deep antiquotation #5665

vicuna opened this issue Jun 28, 2012 · 7 comments

Comments

@vicuna
Copy link

vicuna commented Jun 28, 2012

Original bug ID: 5665
Reporter: @bobzhang
Status: closed (set by @diml on 2016-12-07T17:27:40Z)
Resolution: open
Priority: normal
Severity: feature
Category: -for Camlp4 use https://github.com/ocaml/camlp4/issues
Monitored by: @glondu

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

@vicuna
Copy link
Author

vicuna commented Jun 28, 2012

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.

@vicuna
Copy link
Author

vicuna commented Jun 29, 2012

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

@vicuna
Copy link
Author

vicuna commented Jun 29, 2012

Comment author: @bobzhang

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

@vicuna
Copy link
Author

vicuna commented Jul 5, 2012

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.

@vicuna
Copy link
Author

vicuna commented Jul 5, 2012

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

@vicuna
Copy link
Author

vicuna commented Jul 5, 2012

Comment author: @bobzhang

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

@vicuna
Copy link
Author

vicuna commented Dec 7, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant