irmin.type: test the pp_ty operation
#968
Conversation
|
Rebased. |
craigfe
force-pushed
the
test-pp-ty
branch
2 times, most recently
from
246191b to
5ab226a
Compare
| in | ||
|
|
||
| (* Test cases for basic types *) | ||
| test "unit" T.unit "Prim Unit"; |
There was a problem hiding this comment.
Is Prim really necessary here? Maybe the printer should just omit these.
There was a problem hiding this comment.
Agreed 🙂 I've included this in my list of suggestions in the PR description.
I think it's good to test the existing behaviour first.
There was a problem hiding this comment.
Hum yes I jumped directly to the code without reading the description, feel free to ignore my comments ;-)
| test "array {size=3}" T.(array ~len:(`Fixed 3) unit) "Array:<3> (Prim Unit)"; | ||
|
|
||
| (* Test cases for algebraic combinators *) | ||
| test "enum" Algebraic.my_enum_t "Variant"; |
There was a problem hiding this comment.
Do we want to be a bit more precise for variants and records? I guess these printers are just for debugging anyway, but we could imagine extending them one day to become proper schemas, and having a precise printer would help parsing. I agree this is clearly not very urgent to do :-)
|
Thanks! Let's do the improvement in new PRs as the current one already improved the current situation quite a bit. |
Resolves #959. In the same vein as #965, test the behaviour of the
Irmin.Type.pp_tyoperation. Found and fixed a format string bug in doing so.Shares a LCA with #965 for the
ppx_irmindependency.Some thoughts about the current behaviour:
Primnode could be skipped during pretty-printing;Custom (foo)is reallyLike (foo)from a user perspective;int listrather thanList (Prim Int)).