Summarize of my suggestions:<div> I wrote 3 blogs(<a href="http://hongboz.wordpress.com/">http://hongboz.wordpress.com/</a>) explaining why Parsetree is not an ideal candidate for meta-programming.</div><div> I express my worries if ppx is widely used</div>
<div> <a href="http://lists.ocaml.org/pipermail/wg-camlp4/2013-January/000140.html">http://lists.ocaml.org/pipermail/wg-camlp4/2013-January/000140.html</a></div><div> </div><div> Some arguments why Fan is a better candidate than ppx</div>
<div> 1. Fan is much much faster than P4 (10~20 times)</div><div> 2. Fan does not require any compiler change, easy to distribute, on the contrary the pervasive change to compiler is close to kill P4, Fan or any other advanced external tools, unlike P4, it will</div>
<div>not inhibit OCaml's compiler's progress.</div><div> 3. It's easy to build in Fan, Fan can recognize its syntax on its own, without external tool's help</div><div> 4. It's easy to port P4's code base to Fan, it only takes me 2 hours to port Alain's ulex to Fan(I also make it available on the toplevel, this feature is not available in sedlex or ulex)</div>
<div> 5. Global Ast Rewriter is available but discouraged</div><div> 6. Local Ast Rewriter is provided(deriving and type_conv conflicts will never happen in Fan)</div><div> {:ocaml| type u = A of int |}</div><div>
{:derive| (sexp,json) |}<br> 7. Fan's notation is uniform</div><div> only {:| |} is introduced, I am a bit headache when seeing so many notations</div><div> 8. Fan provides first class parser lexer(or in-line parser/lexer) as a library</div>
<div> 9. Last but not least, Compatibility is important</div><div> If we are un-satisfied with a tool, the right approach is to find a way to repair it, building something from scratch and discard the old tool may not be wise.<br>
<br><div class="gmail_quote">On Wed, Feb 6, 2013 at 1:11 PM, Leo White <span dir="ltr"><<a href="mailto:lpw25@cam.ac.uk" target="_blank">lpw25@cam.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Maybe a single post<br>
summarizing the main proposals and points of contention?<br>
</blockquote>
<br></div>
I will attempt a summary of the parts of the discussion that I remember. In no particular order the following has been discussed:<br>
<br>
<br>
1. Current uses of camlp4<br>
<br>
There were many examples of current uses of camlp4 given. Gabriel put a summary of them on a wiki:<br>
<br>
<a href="https://github.com/gasche/ocaml-syntax-extension-discussion/wiki/Use-Cases" target="_blank">https://github.com/gasche/<u></u>ocaml-syntax-extension-<u></u>discussion/wiki/Use-Cases</a><br>
<br>
Anil also posted a list of all the extensions used by OPAM packages:<br>
<br>
<a href="https://github.com/avsm/opam-camlp4-analysis/wiki" target="_blank">https://github.com/avsm/opam-<u></u>camlp4-analysis/wiki</a><br>
<br>
I don't think anyone has systematically gone through these yet, but I think that it is important, before any concrete proposal is made by this working group, to make clear which of these extensions we intend to support and how we intend to support them.<br>
<br>
<br>
2. New syntaxes needed for ppx:<br>
<br>
There seems to be general agreement that, for ppx to replace camlp4 for its<br>
most common uses, at least the following three kinds of syntax are needed:<br>
<br>
a) A "template" syntax along the lines of (:longid expr). This syntax could be used as an expression, a pattern, a structure item, etc.<br>
For example Sedlex could be:<br>
(:sedlex<br>
match buf with<br>
| number -> ..<br>
| letter, Star ('A'..'Z' | 'a'..'z' | digit) -> ..<br>
)<br>
b) An "attribute" syntax along the lines of (@ expr). This syntax allows you to attach expressions to other expressions, patterns, etc. Unlike the template syntax, the type-checker can silently ignore any of these that don't get translated. For example Bisect could be:<br>
<br>
let f x =<br>
match List.map foo [x; a x; b x] with<br>
| [y1; y2; y3] -> tata<br>
| _ -> (@ Bisect.visit) assert false<br>
<br>
(@ Bisect.ignore)<br>
let unused = ()<br>
It has also been suggested that there might need to be different syntax for "post-fix" and "pre-fix". Gabriel suggested that whether an attribute in a particular syntactic position is pre-fix or post-fix be decided on a case by case basis.<br>
<br>
c) A quotation syntax like {x{ .. }x} (where x is any operator symbol) that could be used for quoting non-OCaml syntax. For example sedlex with a more compact notation for regular expressions:<br>
<br>
(:sedlex<br>
match lexbuf with<br>
| {{ xml_letter+ }} -> ...<br>
| {{ "with" }} -> ...<br>
| ...<br>
)<br>
<br>
There has also been some agreement, and no strong objection, to including some abbreviated forms of the above syntaxes. Some of the suggested forms include:<br>
<br>
a) Template + quotation: {:id x{ str }x} == (:id {x{ str }x})<br>
<br>
b) Template + let: let:id x = .. in ... == (:id let x = .. in ... )<br>
<br>
c) Template + match:<br>
match:id exp with .. == (:id match exp with .. )<br>
<br>
d) Type-conv style attribute:<br>
type t = ... with foo, bar( expr ) == type t = ... (@foo) (@bar expr)<br>
<br>
e) Anonymous template:<br>
(# expr) == (:(*no id*) expr)<br>
<br>
<br>
3. Anti-quotations<br>
<br>
There has been some discussion about how to support anti-quotations:<br>
<br>
- Fabrice suggested using a standardised format for anti-quotations, but some people were against that because they use "$" in their camlp4 quotation extensions.<br>
<br>
I suggested that if we provided functions which took a predicate function and then parsed an OCaml phrase up until the next *unnested* location that made the predicate true, then we could support general anti-quotations for ppx.<br>
<br>
- Hongbo suggested that AST lifting was necessary for supporting anti-quotations, citing this paper:<br>
<br>
<a href="http://dl.acm.org/citation.cfm?id=1291211" target="_blank">http://dl.acm.org/citation.<u></u>cfm?id=1291211</a><br>
<br>
I suggested that it isn't necessarily needed, and that if people wanted it then it could be provided using a type-conv style extension or run-time types.<br>
<br>
<br>
4. On the use of "quotations"<br>
<br>
There has also been some discussion about when it is a good idea to use a camlp4-style quasi-quotation:<br>
<br>
- Alain suggested that they should not be used for extensions that are "mostly valid OCaml code". He pointed out that doing so causes you to lose all editor and tool support.<br>
<br>
Hongbo disagreed saying that in Fan extensions like sedlex would be implement as quasi-quotation and that editor support was fine.<br>
<br>
After this there seems to have been some agreement that it would be better to implement such extensions as "templates" (see section 2 of this post) rather than quasi-quotations.<br>
<br>
- Alain then went further, suggesting that quotations were not even suitable for encoding foreign languages in OCaml.<br>
<br>
Gabriel disagreed, saying that for domain-specific foreign languages (e.g. SQL) quotations allow you to have a domain expert maintain the foreign code even if they didn't know OCaml.<br>
<br>
Other people also said that they liked using quotations for foreign syntax.<br>
<br>
<br>
5. Alternatives to ppx<br>
<br>
There have been some proposals for alternatives and variations to using ppx for extensions:<br>
<br>
a) Hongbo suggests that his Fan project is a better alternative to camlp4 than ppx:<br>
<br>
<a href="https://github.com/bobzhang/Fan" target="_blank">https://github.com/bobzhang/<u></u>Fan</a><br>
<br>
b) Xavier Clerc suggested that attributes might be declared and typed, as in Java. So before an attribute could be used:<br>
<br>
(@ MyAnnot {a=1, b="two"})<br>
<br>
"MyAnnot" would have to be declared with fields "a" (of type "int") and "b" (of type "string"). He points out that this may protect the user from some typos and other obvious errors.<br>
<br>
Alain suggested that this would be a much more complicated system, and might be too restrictive for some uses of attributes.<br>
<br>
c) Sebastien Mondet suggested that run-time types or dyntype might be sufficient without ppx for many extensions.<br>
<br>
Markus Mottl pointed out that there are runtime performance implications for using those solutions.<br>
<br>
d) Jeremy suggested that rather than implementing extensions as AST transformers that operate over the whole AST they might be implemented as transformers only for the part of the AST that they were to operate on. So an extension used like this:<br>
<br>
(:perform<br>
x <-- m;<br>
y <-- n;<br>
return (x y))<br>
<br>
would be implemented as a function with type:<br>
<br>
val perform : Parsetree.expression -> Parsetree.expression<br>
<br>
He suggests that this may help with scoping, safety and compositionality.<br>
<br>
Alain pointed out that some legitimate uses of ppx don't work nicely with the constraint that they can operate only on a marked fragment. He also pointed out that handling extensions as those extensions are found within the source forces a top-down expansion order, which is not necessarily desirable.<br>
<br>
e) I suggested an extension to Jeremy's proposal. This involves giving the expansion functions in their own kind of file (".mlq" - compiled to ".cmq"), referring to them using a namespace mechanism, and then having the compiler itself perform the expansion of the extensions.<br>
<br>
There are more details in my blog post:<br>
<br>
<a href="http://www.lpw25.net/2013/02/05/camlp4-alternative-part-2.html" target="_blank">http://www.lpw25.net/2013/02/<u></u>05/camlp4-alternative-part-2.<u></u>html</a><br>
<br>
Since such a solution would take a while to implement, and since moving an extension from ppx to it would be trivial, I proposed using ppx for the short/medium term.<br>
<br>
I suggested that such a mechanism might improving tooling and make it easier for average users to use extensions.<br>
<br>
Both Gabriel and Alain suggested that the use of namespaces might be unnecessary and too heavyweight. Alain also questioned the need for special ".mlq" files.<br>
<br>
<br>
There are probably other parts of the discussion that I've forgotten. I'm sure someone will fill-in any important details I've missed.<div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
wg-camlp4 mailing list<br>
<a href="mailto:wg-camlp4@lists.ocaml.org" target="_blank">wg-camlp4@lists.ocaml.org</a><br>
<a href="http://lists.ocaml.org/listinfo/wg-camlp4" target="_blank">http://lists.ocaml.org/<u></u>listinfo/wg-camlp4</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>-- Regards, Hongbo
</div>