use ppx to reduce boilerplate code

[vogler]

Use type-driven code generation to get rid of boilerplate (see ppx_deriving):

• [x] yojson for output of domains values (see #210)
• [ ] show for output of domains values (see #213)
• [x] eq, ord for domains (PR #227)
• [x] hash: ppx_hash exists, but depends on and builds around Jane Street Base hash stuff, which conflicts with our base.ml..., and it doesn't seem to support all the primitive types eq and ord derivers do (e.g. char); alternatively implement own more direct deriver https://github.com/sim642/ppx_deriving_hash?
• [ ] relift (#1095)
• [ ] create ppx drivers for own ideas (e.g. names/lifting of modules)
  • [ ] Derive Product-, Record-domain (ppx-lattice branch, PR #1095)
  • [ ] Derive Flat- and Chain-Domain from variant types
  • [ ] Derive name () from Domain name
  • [ ] Derive Lifted functions

[sim642]

At some point I found ppx_yojson, which attempts to simplify manual creation of Yojson values, e.g. by converting OCaml record-like syntax to a JSON object. It's not for deriving anything but just avoids having to construct Yojson values directly using its constructors.

This might be useful for manual implementations of to_yojson, which @keremc is adding more of. Although I think all those manual implementations are simple enough (e.g. a single string) that this isn't really worth it, but I'm still mentioning it here so I can close the tab...

[sim642]

I happened upon ppx_type_directed_value, which Jane Street just has, but I've never heard of anyone using. Its idea being to make custom deriving plugins easier to define by not having to write a ppx deriver from scratch but just define the behavior for product and sum types and have it automagically work for all tuples, records, etc.

It sounds like a nice way to define our own lattice derivers, but it adds the Jane Street Base dependency and has notable performance implications:

The usage of this PPX does incur a runtime cost proportional to the size of the type (e.g. number of fields/constructors/elements in a record/variant/tuple). In particular, if the type-directed value is a function type, there will be a runtime cost on every invocation of the function.

In their benchmarking example they reimplement equality deriving, which via this ppx is ~4× slower than a direct equality deriver. So I'm a bit skeptical if it'd be fast enough to replace our currently hand-written lattice definitions.