Besides, I would really appreciate that we don't introduce <b>too many ad-hoc rules</b>. typing several more characters is ok, typing hundred lines of code does matter.<div><br></div><div>Haskell already suffers from its too flexible syntaxes, think about haskell-src-meta which is a Haskell front-end, can not parse Haskell correctly due to the fact that haskell's operator precedence is dynamic.</div>
<div> <br><div>So far, to my best knowledge, all the feature requests should be not too hard to implement or already exist  in Fan(without changing the grammar), so I do hope that we don't introduce too much complexity in Parsetree for little benefit or <b>making tooling too hard.</b> </div>
<div><br></div><div>Only one syntax extension I think revised syntax did in a write way is</div><div>match with [ ... ], the closed brackets really helps to avoid a lot of bugs.<br><br><div class="gmail_quote">On Thu, Jan 31, 2013 at 9:29 AM, Gabriel Scherer <span dir="ltr"><<a href="mailto:gabriel.scherer@gmail.com" target="_blank">gabriel.scherer@gmail.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">>>> What about nested uses of the same quotation?<br>
>>><br>
>> Handled like nested comments, assuming the lexer knows where the<br>
>> anti-quotations are.<br>
><br>
> An assumption that I really don't think we should make. It involves forcing<br>
> a particular style of anti-quotation on all extensions. Besides it is easier<br>
> to simply use a syntax that supports unique delimiters.<br>
<br>
</div>Note that there is a nice continuum in the design space for<br>
compromises between syntactic flexibility and easy tool support<br>
(assuming non-smart, non-extensible tools that know how to handle<br>
OCaml code):<br>
<br>
0) Pure OCaml syntax : combinator libraries, etc. (note: this is where<br>
the mixfix discussion fits)<br>
1) Alain's style of all-OCaml expressions, using annotations to denote<br>
the domain-specific semantics (tool support for the whole expression)<br>
2) Quotations with an agreed-upon antiquotation syntax (tool support<br>
inside antiquotations)<br>
3) Quotations with extension-custom antiquotation syntax (no tool<br>
support; treated like a string)<br>
<br>
I would be interested in seeing which use cases can be satisfyingly<br>
encoded under which approaches. I personally suspect that for<br>
small-scale syntax supports (say, regexps), the outer quotation syntax<br>
being too heavy is more problematic that any antiquotation syntax<br>
considerations (because if it needs to be short it probably doesn't<br>
have antiquotations besides possibly a custom syntax to denote OCaml<br>
variables, that need no editor support).<br>
<br>
(Note: to my knowledge, Hongbo was the first to remark (<br>
<a href="http://caml.inria.fr/mantis/view.php?id=5665" target="_blank">http://caml.inria.fr/mantis/view.php?id=5665</a> ) that the Camlp4 syntax<br>
for antiquotations was problematic for nested *antiquotations*. That's<br>
a cogent point that can also be taken into consideration, and<br>
something I like about his work on Fan. The use cases for this are<br>
however quite specialized, so it will be easy to counter-argue that<br>
those considerations are for the Fan-class of preprocessing, not the<br>
included-in-the-language-itself one.)<br>
<div class="HOEnZb"><div class="h5"><br>
On Thu, Jan 31, 2013 at 3:02 PM, Leo White <<a href="mailto:lpw25@cam.ac.uk">lpw25@cam.ac.uk</a>> wrote:<br>
> On Jan 31 2013, Török Edwin wrote:<br>
><br>
>> On 01/31/2013 03:56 PM, Leo White wrote:<br>
>>>><br>
>>>> What do you think of this syntax:<br>
>>>> {:lid|...|lid:}<br>
>>><br>
>>><br>
>>> What about nested uses of the same quotation?<br>
>>><br>
>><br>
>> Handled like nested comments, assuming the lexer knows where the<br>
>> anti-quotations are.<br>
><br>
><br>
> An assumption that I really don't think we should make. It involves forcing<br>
> a particular style of anti-quotation on all extensions. Besides it is easier<br>
> to simply use a syntax that supports unique delimiters.<br>
><br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> wg-camlp4 mailing list<br>
> <a href="mailto:wg-camlp4@lists.ocaml.org">wg-camlp4@lists.ocaml.org</a><br>
> <a href="http://lists.ocaml.org/listinfo/wg-camlp4" target="_blank">http://lists.ocaml.org/listinfo/wg-camlp4</a><br>
_______________________________________________<br>
wg-camlp4 mailing list<br>
<a href="mailto:wg-camlp4@lists.ocaml.org">wg-camlp4@lists.ocaml.org</a><br>
<a href="http://lists.ocaml.org/listinfo/wg-camlp4" target="_blank">http://lists.ocaml.org/listinfo/wg-camlp4</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>-- Regards, Hongbo
</div></div>