[wg-camlp4] Structured comments, shallow embeddings and deep quasiquotations
lpw25 at cam.ac.uk
Tue Feb 5 15:57:30 GMT 2013
>I don't really like Leo's proposal.
>On the semantic side, I very much like Jeremy's idea
There is no fundamental difference between the two ideas. There are
problems with trying to use functions within modules as extensions. My
proposal is simply that we can get around this by attaching the functions
>On the practical side, adding a notion of staged compilation
I'm not suggesting any notion of staged compilation. The whole point of
separating functions for extensions from modules is to avoid this issue.
>namespaces to handle syntax extensions seems really overkill.
Namespaces are going to be included anyway, there is no harm in using them
to help make syntax extensions easier.
>A reasonable compromise I would see between the point of view of Alain
>and Jeremy/Leo is to have an "unsafe" interface for global
>preprocessing, which we would discourage people from using by being
>very good at breaking backward compatibility (we can do better than
>Camlp4!), and *maintaining* at the same time one or several safer
>entry point that provide the local structure and conventional syntax
>that we think will bring more robustness to syntax extensions (like
>type-conv can currently be seen as a protective hub around type-driven
I agree. My proposal is not instead of ppx. It is a safer and easier-to-use
alternative for a large subset of the extensions ppx can support. It is a
more long-term option, for the short/medium-term we should use ppx.
>Leo, I'm a bit unclear on what kind of
>GADT you're thinking of, could you elaborate?
Nothing fancy, just something like:
type 'a ctx =
ExprQuot: string -> Ast.expr ctx
PattQuot: string -> Ast.patt ctx
ExprAst: Ast.expr -> Ast.expr ctx
PattAst: Ast.expr -> Ast.patt ctx
>Must we link extension functions together
I'm not sure I understand what you mean by this. Could you expand?
More information about the wg-camlp4