Add compare/equal/etc instances to FrontC abstract syntax

[alpha-convert]

Adding these ppx instances allows for better compatibility with Core.

[ivg]

I like the idea but here are a few of caveats. First of all, this PR doesn't really do anything as all those deriving attributes are just ignored. To get it work you also need to add a preprocess stanza to the dune file. This, in turn, will make us dependent on processors. We would also need to open Base or some other libraries to get functions, e.g., compare_int, etc, that are necessary for the derivers to work.

Now it will bring us to the next few questions:

1. Should we depend on Base or minimize the number of dependencies just to the rewriters and provide corresponding functions manually?
2. Should we at all depend on derivers or pregenerate the code using deriving_inline instead?
3. Even with the inlined derived code we will still depend on ppx_sexp_conv_lib and ppx_hash_lib, so is introducing those dependencies justified?

Besides, compare and equal derivers can get without any extra dependenices. Concerning sexp and hash they are strictly speaking much less neccesary. The sexp_of functions that are necessary for various data structures in JS could be substituted with sexp_of_opaque and Hashtbl.hash is still the best choice.

Finally, even without compare and equal the life is possible, as Poly.compare with Poly.equal work the best with AST data structures. To make people that use janestreet librarues happy, wouldn't it be better for us to manually provide corresponding functions (e.g., compare_foo and equal_foo that just use polymoprhic comparison underneath the hood?

So, while I like the idea in general, I would like to discuss all these questions before. So far, I don't think that it is worthwhile to drag Janestreet dependencies here and would prefer to provide manually written compare and equal functions (probably per each type as well).

You opinions?

[ivg]

• show: it is not a part of janestreet derivers
• sexp_of, why not sexp?