[#879] Get rid of lots of KnownList stuff and record splitting/appending

Description

Recursively splitting appending records in Generic code is inefficient and requires lots of "unnatural" constraints. Restructure implementations to avoid that lots of places.

Related issue(s)

Resolves #879 (closed)

Checklist for your Merge Request

Related changes (conditional)

• Tests (see short guidelines)

  • If I added new functionality, I added tests covering it.
  • If I fixed a bug, I added a regression test to prevent the bug from silently reappearing again.

• Documentation

  • I checked whether I should update the docs and did so if necessary:
    • Root README and other README.md files
    • Haddock
    • docs/
  • I updated changelog files of all affected packages released to Hackage if my changes are externally visible.

Stylistic guide (mandatory)

• My commits comply with the following policy.
• My code complies with the style guide.

assigned to @david.feuer

added 1 commit

• 989b7d6f - fixup! Continue the work

Compare with previous version

marked this merge request as draft from 989b7d6f

added 1 commit

• 4c820f01 - Restructure generic deriving

Compare with previous version

added 1 commit

• 96424869 - fixup! Restructure generic deriving

Compare with previous version

marked this merge request as ready

changed title from Draft: WIP: Get rid of lots of KnownList stuff and record splitting/appending to [#879] Get rid of lots of KnownList stuff and record splitting/appending

marked the checklist item If I added new functionality, I added tests covering it. as completed

marked the checklist item If I fixed a bug, I added a regression test to prevent the bug from as completed

marked the checklist item Root README and other README.md files as completed

marked the checklist item Haddock as completed

marked the checklist item docs/ as completed

marked the checklist item My commits comply with the following policy. as completed

marked the checklist item My code complies with the style guide. as completed

added 1 commit

• 483cd6b8 - Restructure generic deriving

Compare with previous version

requested review from @lierdakil, @pasqu4le, and @alios1

Why do we have this limitation? Can't we just shift over to Product machinery once we get to a constructor?

I'm not as familiar with this part of the code base, so couldn't really tell you without doing a deep dive myself. Perhaps @Martoon could answer this.

Okay, I looked into it a bit, and the reason seems to be we don't really need it, and the implementation is convoluted enough as is without adding support for that as well. Consider that in terms of Michelson, data MyType = C1 Integer | C2 Natural String is representationally equivalent to data MyType = C1 Integer | C2 (Natural, String), and the latter works with the current machinery just fine.

If you think it's possible to make it work without sweeping changes and too much time investment, feel free to try (probably in a separate MR though). From what I dug up in the last half hour or so, it's not as straightforward as one may hope, so it's perfectly fine to leave it be, I think.

We generally don't support such constructs in Lorentz, the primary reason was that there seem to be no general way to implement GetCtorField and respectively unsafeUnwrap/caseT for constructors with multiple fields (or I just didn't find it).

So we really support only bare sum types and bare product types at the moment. But if we start supporting mix of sum and product types, that would be definitely an improvement for UX, though quite a lot of code will have to be updated all over the place.

removed review request for @pasqu4le, @lierdakil, and @alios1