[wg-camlp4] Time for a summary?

[Gabriel Scherer]

On Mon, Feb 11, 2013 at 11:28 AM, Alain Frisch <alain.frisch at lexifi.com> wrote:
>  - Clean up some of its rough edges (or introduce a variant of Parsetree
> which looks more like a parse tree than an AST; I'm not completely decided
> on that point yet).

Independently of whether we use a separate AST format for syntax
extensions to work on, I have concluded from the -bin-annot work that
we want the surface information to be maintained until the typetree if
possible in a non-invasive way (which enables the promise of doing
typedtree-level manipulation in a way that can be explained back to
the user in terms of her code), so I'm interested in the "keep more
concrete syntax details"-kind of changes bubbling up to the parsetree
and typedtree.

On Mon, Feb 11, 2013 at 11:28 AM, Alain Frisch <alain.frisch at lexifi.com> wrote:
> On 02/07/2013 08:50 PM, Hongbo Zhang wrote:
>>
>> On Thu, Feb 7, 2013 at 11:37 AM, Alain Frisch <alain.frisch at lexifi.com
>> <mailto:alain.frisch at lexifi.com>> wrote:
>>     I don't follow. We are talking, basically, about adding simple
>>     constructions to the AST, like:
>>
>>        Pexp_annotation of expression * expression
>>        Pexp_extension of string * expression
>>
>>     and you were suggesting that this would almost kill Camlp4/Fan. Why?
>>
>> The problem is that I am a bit unclear how to encode them in the
>> meta-level, since the introduced constructs will not be consumed by the
>> type checker, they are provided for the convenience of ppx, but does not
>> exist in real world.  I think camlp5 and Coq maintainers will also
>> appreciate that we are a bit conservative in the compiler part.
>
>
> Again, I'm lost.  Why is that difficult to support the suggested extensions
> to the grammar of OCaml in camlp4/camlp4/fan?  The fact that attributes are
> ignored (or propagated) by the type-checker does not change anything:
> Pexp_annotation is just like a binary operator from a syntactic point of
> view.  And what has Coq to do with it?
>
>
>> First, I guess most people will seldom write ppx, and they have to
>> remember all those function names for once use a year. Quosi-quotation
>> is so intuitive that you don't need remember anything.
>
>
> Yes, to write (robust) code generators or transformers, you need to know
> about the OCaml AST.  I suspect most people who have written Camlp4
> extensions are somehow familiar with the OCaml parse tree.  And we should
> make the Parsetree more accessible:
>
>  - Clean up some of its rough edges (or introduce a variant of Parsetree
> which looks more like a parse tree than an AST; I'm not completely decided
> on that point yet).
>
>  - Provide a tool / compiler command-line option to dump a fragment of
> parsed source code in "Parsetree" syntax (as discussed with X. Clerc on this
> list).
>
>
>
>
>> Second, as I said, quosi-quotation works so nice with IDE or Emacs,
>> since you can expand code any time you want, just one key binding, the
>> expanded code just show up in my emacs buffer
>
>
> Could you clarify how this would work?  My understanding of quotations in
> Fan is still that they should be completely ignored by editors, because you
> can put arbitrary syntax in them, so it doesn't make sense to apply OCaml
> "rules" (coloring, indentation, folding, etc) to them.
>
>
>
>> Third, this way to construct code is very limited, think about how you
>> encode the ast, "{:expr| {:expr| a + b|} |}"
>
>
> It's a good example of something I've never wanted to do and which is not
> required to implement any of the "extensions" I'd be interested to use.
>
>
>
> Regards,
>
>
> Alain
> _______________________________________________
> wg-camlp4 mailing list
> wg-camlp4 at lists.ocaml.org
> http://lists.ocaml.org/listinfo/wg-camlp4