Discussion about compatibility

[ghost]

This sums up a discussion we had with @hhugo this morning. There is no action to take on this ticket, I'm just leaving it here so that the plan is clear and in case others want to chime in.

The API of ppxlib is based on a selected version of the AST. This version is not fixed forever and will move from now and then. It will likely change shortly after every new release of the compiler. This means that projects using ppxlib might break every time the selected version of the AST is updated.

The planned solution is to integrate ppx_view into ppxlib for the 1.0.0 release of ppxlib. With ppx_view, we can provide a stable API to deconstruct the AST. Coupled with a stable API to construct the AST and the various traversal classes provided by ppxlib, this will allow ppx rewriters to replace some or all of their explicit references to the concrete data types of Parsetree.

Another other solution would be to do like ocaml-migrate-parsetree and ppx_tools and provide several versions of the whole ppxlib library. However, I believe that the cost will be too high in terms of both maintainability and complexity of the overall system.

[rgrinberg]

this will allow ppx rewriters to replace some or all of their explicit references to the concrete data types of Parsetree

Are there cases where this can't be avoided? Cases where you're forced to use the concrete types from the parsetree. It would be nice if there was a guaranteed subset of ppxlib that you could use without having to depend on any parsetree types.

[ghost]

Nope, the parsetree can be abstracted entirely