[wg-camlp4] Time for a summary?

[Alain Frisch]

On 2/7/2013 2:16 PM, Gerd Stolpmann wrote:
> Currently, there is no documentation about parsetrees, and I would need
> to guess how they are built up. But if there was some documentation plus
> some examples it would probably be fully acceptable.

See the discussion with X. Clerc on this list.  It has been suggested to 
add a compiler option to dump the parse tree into "Parsetree" syntax 
(Pexp_... constructors).

> "let rec" might be a bad example, because such a change is not expected,
> but generally we _will_ run into the problem that changes of the
> parsetree type break ppx processors. (Well, to some degree we can avoid
> this by having wrapper functions, i.e. don't use E.let_ directly, but a
> function mk_let, as then many changes can be done in a way that doesn't
> affect compatibility.)

E.let_ is already a wrapper around the constructor:

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))

If the Parsetree is extended, there are different ways to organize 
ourselves to avoid breaking existing -ppx rewriters (at least for AST 
fragments "builders", not "patterns"): new functions, optional 
arguments, a copy of the ast_mapper module to support older versions of 
the Parsetree (with an implicit mapping).  But it also make sense to 
think about ways to make the definition of Parsetree itself more robust 
to future changes.  For instance, using records instead of tuples is 
much more future-proof:  when deconstructing a node, one can choose to 
use "open record patterns" (to explicitly ignore future fields which 
could be added) or not (to be forced to adapt the code if more fields 
are added);  and wrapper functions can use optional arguments for new 
fields.


Alain