Might it make sense to upstream this to ppxlib.metaquot?

[pitag-ha]

If I'm not missing anything, this version of metaquot is strictly better than ppxlib.metaquot in the sense that its features are a super-set of the ppxlib.metaquot features. Is that right? Are there maybe also some downsides to it that I'm currently not seeing (performance or similar)?

I think it would be great to discuss the context around that a little! Concretely, why is this a separate project instead of being upstreamed to ppxlib.metaquot? Are there any technical issues that upstreaming it would involve? Are some of the features that are here and not in ppxlib.metaquot controversial?

Of course, we wouldn't upstream this from one day to another, but it might be worth looking into that, so I'd love to hear your opinion @thierry-martinez!

[thierry-martinez]

I started `metaquot` before `ppxlib` ceased to be able to work with other `ppx` drivers. The initial goal was to have a "metaquoter" targetting the current version of the compiler AST, this goal is now deprecated since all `ppx` rewriters should use the `ppxlib` driver now (otherwise, they didn't compose with anything using `ppxlib`), and `ppxlib` imposes its fixed version of the compiler AST. I adapted `metaquot` minimally to be usable with `ppxlib` (by targetting the `ppxlib`-versioned AST), so that my other projects that was relying on `metaquot` don't break (and work with `ppxlib`), but ideally everyone should use `ppxlib.metaquot` now. I am not sure that additional features of `metaquot` are worth being integrated to upstream `ppxlib.metaquot`: it was mainly a playground for me to experiment some facilities, but I don't know if we want to pay the maintenance burden. The most interesting thing I see in `metaquot` is that it is mainly automatically generated by preprocessing compiler-libs' Parsetree module with `metapp`, but `ppxlib.metaquot` has a very different design. I would be glad if `metapp` itself becomes more visible in the `ppx`-ecosystem, because I think it could be very useful for the community, but it doesn't seem to be liked (I certainly failed to promote it well, but the couple of announces I made on it didn't catch much attention).

[pitag-ha]

Thanks for the context and history on this, that's very interesting! I understand far better now why this metaquot co-exists with ppxlib.metaquot.

The most interesting thing I see in metaquot is that it is mainly automatically generated by preprocessing compiler-libs' Parsetree module with metapp

I see! Part of that might be similar to ppxlib.metaquot, which uses a "lift" class that's generated by preprocessing the Ppxlib AST: a class that for each node in the Ppxlib AST provides a method to capture that node representation in the given target: expression or pattern.
And about metapp: I think the reason why in this metaquot it comes in very useful (and in ppxlib.metaquot it's not needed) is that here you need to make the cross-compiler compatibility explicit (whereas in ppxlib.metaquot it's abstracted away by using the Ppxlib AST). Is that correct?

I would be glad if metapp itself becomes more visible in the ppx-ecosystem, because I think it could be very useful for the community

metapp does indeed seem very cool! It has a broader use case than ppx_optcomp and cppo, doesn't it? (although, of course, that's a different topic)

I am not sure that additional features of metaquot are worth being integrated to upstream ppxlib.metaquot

The features I was thinking about are [@subst] and [@for]. I've heard some requests about adding those two to ppxlib.metaquot. Have you tried them in some projects of yours and have noticed that they're less useful / more problematic than they seem?

[orbitz]

FWIW, [@subst] would be really great if it got upstream to pplib.metaquot somehow. I find that very useful, otherwise in ppxlib.metaquot I end up having to write out the parse tree by hand too often.