[RFC] Integrate ppx_view about ppxlib

I'm closing this for now. This plan is a step forward but doesn't go far enough. The new plan is to add first a minimal and stable API for ppx rewriters in the compiler, then we will be able to refactor ppxlib and other ppx libraries on top of this new library. Once this is done, changes to the compiler libraries should cause no breakage in the ppx ecosystem. In particular, it will become possible to test development compilers against released opam packages.

I'm currently writing a proposal for the stable API.

I was thinking about this again. If we simply upstream the View and Ast_viewer modules of ppx_view into the compiler directly, then we would get the best possible world: all the ppx ecosystem could use the current AST without any conversion and without risk of breaking with new compiler versions, and the for compiler updating Ast_viewer when changing the parsetree would be no harder than updating Ast_helper.

[trefis]

I'd like to have a look at this before it gets merged if you don't mind.
I'll approve / comment when I'm done.

Sure

[rgrinberg]

Possibly a naive question, but why would do we need to support both builder & helper style for patterns & constructors? Seems like pattern/builder provide nicer conventions, can't we just use those exclusively?

[xclerc]

If memory serves, it was basically to explore the design space.
I implemented toy versions of various ppx rewriters to see how
they would look like; feel free to remove the cruft.

The idea is indeed to support only pattern/builder style. However, the current Ast_pattern should be re-implemented on top of the View module.