[wg-camlp4] Improvements to the OCaml Parsetree

[Romain Bardou]

Le 28/01/2013 16:25, Alain Frisch a écrit :
> Dear all,
>
> Another useful topic for discussion related to -ppx are improvements to
> the OCaml Parsetree itself. Of course, since the Parsetree is "going
> public" with -ppx, it make sense to improve it before too much code
> depend on it.
>
> Let me list of few points I have in mind:
>
> - Get rid of some tuples / n-ary constructors in favor of proper record
> types (self-documented, more future proof). Similarly, prefer explicit
> constructors to "bool" flags (although if we use more records, this is
> less of a problem).

Good.

> - Get rid of weird encodings in favor of more explicit representation.
> For instance, Pexp_when: guard expressions should be explicitly put next
> to patterns (or maybe allowed within the pattern algebra with some
> type-error if they are not at the toplevel). Also, I'm not sure about
> the special "Pexp_assertfalse" node. Do you have another examples?

About assert false as a special node: I think it should stay like this.

It may add a case to treat, but the treatment will usually be trivial. 
If it is not, then it will probably be an instance of the assert case, 
in which case you can just call the assert case with <<false>> as an 
argument. Else it means that you have a very different treatment for 
false and in this case, you’re glad that they are separate.

Moreover, this case really is a special case as it is typed differently. 
I think it is better if the parse tree reflects this, so that the 
programmer is conscious of this when transforming assertions.

> - Be more liberal about where Ptyp_poly must/might appear (the
> type-checker currently expect some dummy Ptyp_poly wrapper in some
> places, and the parser know that).
>
> - Avoid doing too much desugaring in the parser. For instance, we should
> probably distinguish between "let open M in e" and "M.(e)" in the
> Parsetree. Where to stop exactly, I'm not sure. For instance, I don't
> have a clear opinion on whether record field punning should be handled
> purely in the parser or reflected in the Parsetree. What do people here
> think?

That’s a tricky one!!

> - This needs to be discussed, but what about remove those Ptyp_, Pexp_,
> ...., prefixes everywhere? And similarly for record fields (ptype_,
> ...). Now that we have type-based disambiguation of constructors/labels,
> we don't really need those prefixes and they increase the verbosity of
> AST rewriters. Some experimentation is needed, though.

I think it would probably be better if it is actually possible, yes.

-- 
Romain Bardou