<div dir="ltr">Agreed: let's get a bit more experience with which syntax extensions can be expressed with extension and attribute nodes before drawing more conclusions on quasiquotations.<br><div><div></div></div></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 29, 2013 at 8:18 PM, Alain Frisch <span dir="ltr"><<a href="mailto:alain.frisch@lexifi.com" target="_blank">alain.frisch@lexifi.com</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">On 3/29/2013 4:12 PM, Gabriel Scherer wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That is better indeed. I can only encourage you to add these kind of<br>
conveniences in the E submodule (or maybe somewhere else) as usage<br>
suggests that they are useful.<br>
</blockquote>
<br></div>
I believe that a good design for a Convenience submodule will follow the adaptation of existing syntax extension into -ppx style. A first list of convenience functions can be found in:<br>
<br>
<a href="http://caml.inria.fr/cgi-bin/viewvc.cgi/ocaml/branches/extension_points/experimental/frisch/print_gen.ml?revision=HEAD&view=markup" target="_blank">http://caml.inria.fr/cgi-bin/<u></u>viewvc.cgi/ocaml/branches/<u></u>extension_points/experimental/<u></u>frisch/print_gen.ml?revision=<u></u>HEAD&view=markup</a><br>
<br>
(a quick attempt to generate "variantizer" functions from type definitions, here taken from .cmi files)<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm still not sure that quasi-quotations are not a better approach,<br>
because the problem here is that the user has to learn a new interface<br>
to describe code fragments instead of using the syntax he's already<br>
familiar with.<br>
</blockquote>
<br></div>
I think it is very similar with quotations and antiquotations. There are fewer names to know, but this can become more confusing.<br>
<br>
For instance, in:<br>
<br>
<:expr< $xxx:e$ >><br>
<br>
you need different antiquotations names to indicate at least that x is (i) an expression, or (ii) a string to be interpreted as a lower-case identifier, or (iii) a longident, or (iv) a string to be interpreted as a constructor name, or (v) a string to be interpreted as a string literal. Each anti-quotation can be used only in specific contexts. Basically, one recreates a dedicated sub-language, with its own syntax and types, whereas OCaml is not *that* bad at manipulating ASTs.<div class="im">
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I still have the intuition that those arguments are more<br>
relevant to the expert extension writer, and that for a large set of use<br>
cases that concern *simple* extensions and beginner extension writers,<br>
quasiquotations are still noticeably easier to use.<br>
</blockquote>
<br></div>
I wouldn't trust a syntactic tool written by someone who is not quite familiar with the definition of the Parsetree. That said, I've nothing against trying to make writing extensions as simple as possible. I'm personally more interested in providing tools and techniques to support writing robust "non trivial" extensions, but it's a nice observation that the current proposal with extension nodes supports quotation, and I encourage people interested in supporting "concrete syntax" ppx rewriters to push this idea further.<div class="im">
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The question of whether the extension uses classical or revised syntax<br>
is largely orthogonal to the design of the extension itself (except<br>
occasionally with quotation ambiguities concerns), and I could have used<br>
the classic syntax to write the Camlp4 extension just as well.<br>
</blockquote>
<br></div>
Including within quotations? At some time, this was not supported; later it was supported but discouraged, because the standard syntax was not "regular" enough to support non-ambiguous quotations (I don't know the details). But maybe that the status of quotations in regular syntax has changed.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I found that<br>
there was no such re-learning curve with quasiquotations, they just work<br>
out of the box -- once you've been rebrained, once and forall, to see<br>
those <:stuff< >> as structured code rather than ASCII noise.<br>
</blockquote>
<br></div>
Can you tell without looking at the documentation or existing code how to write a function which maps a string s to an AST fragment representing a constructor of name s applied to a single argument, the string literal represented by s. I.e. mapping "Foo" to the AST fragment corresponding to the expression<br>
<br>
Foo "Foo"<div class="im"><br>
<br>
?<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Implementing this "quote" expander is not very difficult, just a<br>
little bit tedious (and this can be automated by parsing the<br>
definition of the Parsetree).<br>
<br>
<br>
Isn't that essentially the same thing as the tool you implemented for<br>
Xavier above? (Can you reuse code between both?)<br>
</blockquote>
<br></div>
This tool relies on the toplevel value printer. I'm not sure it will be easy to suport anti-quotations with this approach.<div class="im"><br>
<br>
> If I understand correctly, this is also the "Meta" operation of<br>
> Camlp4,<br>
> turning the AST for the expression <foo> into the AST for the OCaml<br>
> expression representing the AST for <foo>. When you say "automated by<br>
> parsing the definition of the Parsetree", do you have a realistic<br>
> design<br>
> in mind for such boilerplate code generators, or do you plan in<br>
> practice<br>
> to implement them by hand?<br>
<br></div>
Something similar to branches/extension_points/<u></u>experimental/frisch/<a href="http://print_gen.ml" target="_blank">print_gen.<u></u>ml</a> could be used to generate automatically an AST lifter. The difficult part is to design anti-quotations, though, and since I'm not convinced by this approach, I'd rather put energy myself in other projects.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Same old battle-horse: I dislike the idea that [%quote ] would change<br>
the meaning of syntactically valid OCaml code such as __patvar or<br>
!!patvar.<br>
</blockquote>
<br></div>
Point taken. But since we are already under an "extension", I think this is less bad.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Quasi-quotations would be useful if the expanders had to generate<br>
big fragments of mostly static code, with only a few "dynamic"<br>
placeholders. In my experience, this is rarely the case: you<br>
assemble the resulting OCaml code by combining many small fragments<br>
generated programmatically. For these cases, a nice library of "AST<br>
constructors" seems better to me.<br>
<br>
<br>
Maybe we need both, but if we eventually get nice constructor names for<br>
the AST definitions (I know that doesn't depend on you) I think if we<br>
only had time/energy/maintenance for two among (1) AST definitions (2)<br>
AST combinator library and (3) quasiquotation mechanism, I would suggest<br>
we keep (1) and (3) rather than (1) and (2).<br>
</blockquote>
<br></div>
My preference, as you understood, would be (1) and (2) rather than (1) and (3).<br>
<br>
An interesting project would be to review existing syntax extension and see how much "almost static fragments" (where quasi-quotations shine) they have compared to code assembling tiny fragments (where combinators are betters). I suspect that most interesting tools based on Camlp4 don't have a lot of static fragments, but I might be wrong.<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
-- Alain<br>
<br>
</font></span></blockquote></div><br></div>