-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discuss: PlutusTx Eq instance generation should delegate to BuiltinData equality #236
Comments
PTryFrom in Plutarch is parsing data and yielding a type (it just yields a proof that it is of proper encoding). However, what's the deal with I ask because if I wanted to implement PlutusTx.Eq such that it delegates to underlying To be more concrete if I instance PlutusTx.Eq Foo where
l == r = toData l == toData r I wouldn't necessarily gain anything, as I still traverse the value structures of l and r and construct BuiltinData from it. Right? |
Relevant Plutarch piecesPEq (PAsData a) -> https://github.com/Plutonomicon/plutarch-plutus/blob/780d350f1985e89e3294861118f721d4141b2a6a/Plutarch/Builtin.hs#L471
|
In Plutarch the general consensus is that we perform Eq by simply delegating to the underling PlutusData representation.
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
The text was updated successfully, but these errors were encountered: