[wg-camlp4] Time for a summary?

[Hongbo Zhang]

On Thu, Feb 7, 2013 at 11:37 AM, Alain Frisch <alain.frisch at lexifi.com>wrote:

> On 2/7/2013 3:56 PM, Hongbo Zhang 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.

>
> E is defined in Ast_mapper:
>
> http://caml.inria.fr/cgi-bin/**viewvc.cgi/ocaml/trunk/**
> parsing/ast_mapper.mli?view=**markup<http://caml.inria.fr/cgi-bin/viewvc.cgi/ocaml/trunk/parsing/ast_mapper.mli?view=markup>
>
> For instance, let_ is defined very cleverly as:
>
> let mk ?(loc = Location.none) x = {pexp_desc = x; pexp_loc = loc}
> ...
> let let_ ?loc a b c = mk ?loc (Pexp_let (a, b, c))
>
> There is absolutely no magic.
>
> 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.

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, the experience is exactly the same as
slime in lisp, it's impossible to expand the code using arbitrary functions.

Third, this way to construct code is very limited, think about how you
encode the ast, "{:expr| {:expr| a + b|} |}"


> This is a valid point, and I believe there would not be any strong
> opposition to move some desugaring logic from parser.mly into the
> typechecker, i.e. make Parsetree look more like a parse tree than an AST.
>
> That said, I've no idea what
>
>  `Bigarray (a,b,c)
>
> means.

In Fan, the transformation between concrete syntax and abstract syntax is
bijective(at least the design goal), so there is no ambiguity here, but for
parsetree, it's hard to draw a line here, if you prevent all the syntax
desguaring, that might introduces too much unnecessary complexity for the
type checker

>
>
>
> Will you introduce in Fan the notion of attributes attached to every
> possible category and represented explicitly in the (Fan) AST?  I thought
> you only had the intention to extend the syntax of OCaml with a single
> construct {:xxx| ... |}  with  .... being left unparsed.  I don't see how
> you can simulate "ignorable attributes" with that. Can you elaborate?
>
> I am pretty open-minded here, actually I thought it for a while, I am more
inclined to do this in the parsing stage by providing some plugins without
cluttering the ast too much.

>
>
> Alain
>



-- 
-- Regards, Hongbo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/wg-camlp4/attachments/20130207/1fc6fd85/attachment-0001.html>