Discuss: PlutusTx Eq instance generation should delegate to BuiltinData equality
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- haskell
- Domain
- blockchain, tooling
Research direction
Review the existing PlutusTx Eq instance generation and compare it with the PlutusData equality approach shown in the issue. Read the referenced plutus-ledger-api/src/PlutusLedgerApi/V2/Tx.hs implementation, then resolve how canonical representations for types such as Set and Map should be specified before deciding what constitutes completion.
Written by the indexing model from the issue text.
Description
In Plutarch the general consensus is that we perform Eq by simply delegating to the underling PlutusData representation.
instance PEq FooTrivial where
(#==) = \l r -> pdata l #== pdata r
PlutusData equality operation is a builtin which is naturally much more performant then doing the obvious field by field comparisons (which is done in PlutusTx PLA types and is generally a practice adopted https://github.com/IntersectMBO/plutus/blob/b34d6ca2c4bbe54c324337eb813a5f6a522b475c/plutus-ledger-api/src/PlutusLedgerApi/V2/Tx.hs#L84).
However, we do assume that there's a single canonical PlutusData representation for all types, which might not be the case for semantically richer types like Set or Map (for example, the underlying AssocMap PlutusData representation can use ascending or descending ordering etc). This is solved by agreeing on a well defined PlutusData representation for any type that might be ambiguous in that regard.
cc @peter-mlabs
- Dominant language
- Haskell
- Stars
- 32
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from mlabs-haskell/lambda-buffers
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
mlabs-haskell/lambda-buffers#296 ·
-
Difficulty 5/5 Over a week Newbie friendliness 20/100
mlabs-haskell/lambda-buffers#295 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 20/100
mlabs-haskell/lambda-buffers#294 ·
-
Dykstra HF Open
Difficulty 4/5 3-5 days Newbie friendliness 35/100
mlabs-haskell/lambda-buffers#293 ·
-
Nix-free path Opendevops
Difficulty 5/5 Over a week Newbie friendliness 25/100
mlabs-haskell/lambda-buffers#292 ·
All issues in mlabs-haskell/lambda-buffers
Similar issues
-
typst-0.12 Open
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
commercialhaskell/stackage#8127 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
input-output-hk/haskell.nix#2573 ·
-
docs
Difficulty 1/5 Under an hour Newbie friendliness 85/100
-
needs triage type: bug
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100