suggestion: a shared unit-test for all the deriving plugins

[chetmurthy]

I've noticed that ppx_deriving_yojson has a far more comprehensive testsuite than the other plugins. I think it might be useful if all the various plugin authors contributed to a shared testsuite that ensured that they all met the same high standard that I believe ppx_deriving_yojson meets.

I'm in the process of reimplementing your plugin on top of camlp5, and I'll be producing something like that for myself, for sure. When I get it done, I'll pass along a pointer, but obviously there might still be gaps.

[whitequark]

I'm sorry, reimplementing on top of what?

[chetmurthy]

I'm reimplementing ppx_deriving, ppx_import, and ppx_deriving_yojson (soon, ppx_deriving_sexp) using camlp5: https://github.com/chetmurthy/pa_ppx

I've upgraded camlp5 so it understands all the new syntax up to Ocaml 4.10.0 (well, I might have missed a few things, but eventually I'll write tests to find them) and so now I have what amounts to really nice "metaquotation" (camlp5 calls them "quotations" and "antiquotations") support. And I'm using that to rewrite all the PPX rewriters that seem at all useful.

[chetmurthy]

I should add that tomorrow will be the end of week two of this effort: before that, I was focusing on getting camlp5 to the point where it could properly parse/prettyprint/represent all ofocaml 4.10.0 syntax.

[hhugo]

Are you aware that deriving and deriving_yojson exist for camlp4 (I don't know how much camp4 and camlp5 differ though)

[whitequark]

To be honest, this makes me sad, because my #1 motivation for developing ppx_deriving in the first place was to get rid of camlp4, which in my opinion was one of the major downsides of participating in the OCaml ecosystem.

But I suppose you have your reasons, and I don't really use OCaml anymore anyway.

[chetmurthy]

I knew that all these things existed for camlp4. But (a) camlp4 is incredibly backlevel, (b) didn't support a lot of the stuff camlp5 did, and (c) in any case, even camlp5 was incredibly backlevel, compared to modern Ocaml.

I can appreciate why you didn't like campl4: I didn't like it much either, b/c it was somewhat broken. But OTOH, I think that if it's a choice between (1) writing PPX rewriters using bare Ocaml and some support from ppxlib et al, and (2) writing using camlp5 support, I'm going to choose the latter.

I mean, camlp5 has very well-thought-out support for quotations, and that's more-or-less the most important thing for writing these rewriters. Its extensible functions are also really valuable, I've found.

But whatever: I'm certainly not trying to convince anybody to do this this way: though, if it takes me literally a couple of weeks to rewrite all the useful PPX infrastructure in the world .... well, that does say something about this approach.

What language do you code in these days, just wondering?

[whitequark]

What language do you code in these days, just wondering?

A few; some Rust, but mostly Python, since I found myself maintaining a Python-embedded hardware description language.

I never liked Python at all, but it provides a common ground for a lot of people (in this case, EEs, FPGA/ASIC engineers, etc) who see programming as a means to an end and wouldn't even bother looking into an OCaml-embedded HDL (I considered that, I asked around, I realized it would be a nonstarter).

Plus, with all of Python's flaws, it is still vastly better than the Verilog-2005 (most OSS HDL code) / SystemVerilog (most proprietary HDL code) status quo, which is the reason you see so many embedded HDLs recently (Chisel, SpinalHDL, Clash...)

[chetmurthy]

Fascinating. I'd heard of "BlueSpec" which is apparently a Haskell-derived HDL, but not about one based on Python. is this MyHDL?

[whitequark]

Nope, nMigen (which is a clean slate, backwards compatible reimplementation of Migen).

[XVilka]

@chetmurthy if you are curious about various HDLs, you can read a lengthy discussion and various references here. Note, that there is even one in OCaml - Hardcaml.