Add deriveEq for Plinth similar to deriving stock Eq

[bezirg]

Pre-submit checklist:

• Branch
  • Tests are provided (if possible)
  • Commit sequence broadly makes sense
  • Key commits have useful messages
  • Changelog fragments have been written (if appropriate)
  • Relevant tickets are mentioned in commit messages
  • Formatting, PNG optimization, etc. are updated
• PR
  • (For external contributions) Corresponding issue exists and is linked in the description
  • Targeting master unless this is a cherry-pick backport
  • Self-reviewed the diff
  • Useful pull request description
  • Reviewer requested

[github-actions]

Execution Budget Golden Diff

f96714c (master) vs 97a7b4b

output

plutus-benchmark/cardano-loans/test/9.6/main.golden.eval

Metric	Old	New	Δ%
Flat Size	8_666	8_673	+0.08%

plutus-benchmark/coop/test/9.6/certMpBurning.golden.eval

Metric	Old	New	Δ%
Flat Size	8_031	8_035	+0.05%

plutus-benchmark/coop/test/9.6/certMpMinting.golden.eval

Metric	Old	New	Δ%
Flat Size	8_554	8_558	+0.05%

plutus-benchmark/coop/test/9.6/fsMpBurning.golden.eval

Metric	Old	New	Δ%
Flat Size	7_395	7_399	+0.05%

plutus-benchmark/coop/test/9.6/fsMpMinting.golden.eval

Metric	Old	New	Δ%
Flat Size	9_213	9_217	+0.04%

plutus-benchmark/linear-vesting/test/9.6/main.golden.eval

Metric	Old	New	Δ%
Flat Size	2_860	2_864	+0.14%

plutus-benchmark/nofib/test/9.6/clausify-F5.golden.eval

Metric	Old	New	Δ%
Flat Size	1_477	1_484	+0.47%

plutus-benchmark/nofib/test/9.6/knights10-4x4.golden.eval

Metric	Old	New	Δ%
CPU	1_023_470_754	1_025_262_754	+0.18%
Memory	5_395_058	5_406_258	+0.21%
Flat Size	1_674	1_682	+0.48%

plutus-benchmark/nofib/test/9.6/queens4-bt.golden.eval

Metric	Old	New	Δ%
Flat Size	1_764	1_767	+0.17%

plutus-benchmark/nofib/test/9.6/queens5-fc.golden.eval

Metric	Old	New	Δ%
Flat Size	1_764	1_767	+0.17%

plutus-benchmark/script-contexts/test/V3/Data/9.6/purposeIsWellFormed-4.golden.eval

Metric	Old	New	Δ%
Flat Size	1_839	1_843	+0.22%

This comment will get updated when changes are made.

[SeungheonOh]

I'm not too confident in my ability to review TH code. So perhaps a look from @Unisay would be nice. But everything looks right from what I can tell.

[SeungheonOh]

The great pyramid

[SeungheonOh]

Also, can you check if this works with polymorphic phantom types? I'm curious as per #4537

[bezirg]

Also, can you check if this works with polymorphic phantom types? I'm curious as per #4537

I will test it out

[bezirg]

Also, can you check if this works with polymorphic phantom types? I'm curious as per #4537

Indeed, it does not work with polymorphic phantom types.

I don't know yet how to make it work.
One idea I had is to look at the datatype's kind using https://hackage.haskell.org/package/th-abstraction-0.7.1.0/docs/Language-Haskell-TH-Datatype.html#t:DatatypeInfo .

Unfortunately, it returns me kind the wrong kind *, whereas I was expecting kind forall k. k -> *. If I had the latter kind then I could infer that k is phantom. I think it is too much work , for little benefit. What do you think?

[bezirg]

Also, can you check if this works with polymorphic phantom types? I'm curious as per #4537

Indeed, it does not work with polymorphic phantom types.

I don't know yet how to make it work. One idea I had is to look at the datatype's kind using https://hackage.haskell.org/package/th-abstraction-0.7.1.0/docs/Language-Haskell-TH-Datatype.html#t:DatatypeInfo .

Unfortunately, it returns me kind the wrong kind *, whereas I was expecting kind forall k. k -> *. If I had the latter kind then I could infer that k is phantom. I think it is too much work , for little benefit. What do you think?

I think I can solve this by using plain template-haskell package than th-abstraction wrapper. It would be some work foro refactoring though. Perhaps in another PR?

[Unisay]

Perhaps in another PR?

If a PR is useful improvement even without its follow-up I'd say yes.

[bezirg]

Don't merge yet, I have a bug on "Void" datatypes. They should return True, but instead they return False.