Defending PPXes

#1

Our current eDSL is using API expressible as high-order functions and looks very-very as OCaml code. It’s easy to add macros on top of it using PPX syntax extension.

There are some complaints about it, for example:

  1. we need to use weird operator names because OCaml compiler has built-in rules about associativity of operations
  2. we can’t extend syntax too much, because the code should be parsable by PPXes.

AFAIU, Camlp5 is more powerful than PPXes because it uses it’s own parser and can enhance default grammar to create really fancy DSLs, which can be not parsable by OCaml parser. There are downsides, of course

  1. IDE support will be very weak.
  2. Every wannabee will be lagging in the beginning, because the syntax is completely new (as for every fancy DSL)

These points are completely ignored by opposite side, which wants to implement Camlp5-based syntax extension. Do we have any other points which can be used to… demotivate people about writing Camlp5 syntax extension?

#2

What “other side” are you talking about? I’ve heard literally no one advocate for going back to camlp{4,5} extensions. Personally my beef with ppx is neither 1. nor 2. but the instability of the ecosystem because of the dependency on unstable APIs from compiler-libs. I’ve been told it will eventually be fixed (“this time it’ll be stable, promise”) but until then I’ll imitate @dbuenzli and stick to writing pure OCaml whenever possible.

5 Likes
#3

In my eyes, the main show stopper for a camlp5-based approach is point 1.
I like having a working merlin, ocp-indent, syntax highlighting, etc.; and you lose all of these with camlp5.

Then, as @c-cube mentioned, from a maintainability perspective, there is an inherent cost with both PPX and camlp5 due to their dependency on the evolving syntax/parse tree (and possibly other internal compiler APIs). But then, in the current state of things, there are more people using and invested in maintaining the PPX ecosystem than with camlp5, as far as I can tell. So I would expect PPX to be a more forward looking option in that regard (one big user of camlp5 used to be Coq, but AFAIK they now maintain themselves a stripped-down version of camlp5’s engine, and do not depend on camlp5 per se anymore).

#4

@Armael, Yeah, I agree that fancy IDE features are but as I said these points are ignored by opposite side.

I think that nobody will argue that Camlp5 is more powerful but maybe I can workaround my associativity issues by a hack? For example, is it possible to convert AST with wrong associativity into AST with right associativity automatically?

@Armael, Also, how should I google the stripped down camlp5 in Coq?

#5

If you heard no one it doesn’t prove that no one exists. What do you say to a man who completely ignores API stability issue and care only about how fancy his/her DSL looks like in practice?

#6

Coq < 8.10 used camlp5 to implement the parser for Coq files, and also to provide ocaml syntax extensions for extending the grammar.

Coq >= 8.10 includes a stripped down implementation of the parser taken from camlp5 https://github.com/coq/coq/tree/master/gramlib and replaced the syntax extensions with a ad-hoc preprocessor https://github.com/coq/coq/tree/master/coqpp

1 Like
#7

That I won’t use their code if I can avoid it :innocent:

#8

That particular point is even more pronounced in CamlpN, since it got thrown out of the compiler distribution there is doubt who will update it to the new release this time and whether that will even ever happen. OTOH, CamlpN definitions probably break less than PPX users.