[wg-camlp4] About Ptyp_poly nodes in the Parsetree

[Alain Frisch]

Dear all,

I'd like to get your opinion about the representation of "polymorphic 
types" (Ptyp_poly) nodes in the Parsetree.  Such nodes can only appear 
on specific places (currently as record field type or method type), but 
this invariant is not enforced by the Parsetree definition, thus making 
it possible for AST rewriters breaking it (problem I).  Currently, the 
type-checker would accept such ill-formed types (and probably complain 
later with weird error messages).  Dually, where the type-checker 
supports a Ptyp_poly node, the Parsetree has to be such a node, even if 
the list of quantified variable is empty.  This is enforced by 
parser.mly, but again, AST rewriters can break this invariant (problem II).

Problem II is probably the most serious one in practice, since it forces 
authors of ppx rewriters to insert explicitly Ptyp_poly nodes where needed.

In this commit:

http://caml.inria.fr/cgi-bin/viewvc.cgi?view=revision&sortby=date&revision=13491

I've addressed problem II by pushing to the type-checker the 
responsibility to add "empty" Ptyp_poly quantification wherever needed 
(if the Parsetree is not already a Ptyp_poly node).


Do you think this is enough, or should we do something about problem I 
as well?

A simple option would be to add runtime checks, i.e. ensure that the 
type-checker fails with a proper error message is a Ptyp_poly node is 
found in a context where it is not supported.  This would probably allow 
authors of ppx rewriters to identify problems quickly.  A stricter 
approach would be to encode in the Parsetree definition itself the 
invariant about where Ptyp_poly node can appear.  Concretely, one could 
simply define a type:

  poly_type = string list * core_type

remove the Ptyp_poly constructor, and use poly_type instead of core_type 
where applicable.

This approach is more robust, of course, but also less flexible: tools 
which manipulate Parsetree need to explicitly wrap core_types into 
poly_types where applicable.  And if OCaml ever supports poly types in 
more contexts (e.g. as sum type constructor arguments, which should not 
pose any theoretical problem), the code of the tools will need to be 
changed accordingly.

A variant would be to "inline" the "string list" in the surrounding 
structure (e.g. as an extra field in label_declaration), and use an 
optional argument in Ast_helper to facilitate the creation of those 
structures for the case where the list is empty.

What's your opinion?


Alain