We've discussed before how Plutarch types are merely tags and don't have a direct connection to their runtime representations. It's important to be able to intuitively figure out the runtime representations from the data type declaration though. This is why most types follow certain conventions.
The representation can only be one of two categories: builtin and Scott encoded. All trivial builtin types are already defined
in Plutarch: PInteger
, PByteString
, PString
, PBool
, PUnit
, PBuiltinList
and PBuiltinPair
.
Now, let's discuss patterns of data declarations and what representation they should hint at:
-
If it's an ADT that derives
PlutusType
withDPTStrat _ = PlutusTypeScott
, then the ADTs will be scottencoded. This is what you generally want for non-trivial types that are not stored in datums or redeemers.e.g.
PList
derivesPlutusType
generically and is represented with Scott encoding. -
If it's an ADT that derives PlutusType with
DPTStrat _ = PlutusTypeData
it's data encoded. Particularly, it's aData
value - which is part of the builtin types.e.g.
PScriptContext
derivesPlutusType
usingDPTStrat _ = PlutusTypeData
-
If it's a representationally equal wrapper (think Haskell
newtype
) to a term containing a Plutarch type - it should have the same representation as that underlying Plutarch type.e.g.
newtype PPubKeyHash (s :: S) = PPubKeyHash (Term s PByteString)
is just represented asPByteString
. This is ensured by derivingPlutusType
withDPTStrat _ = PlutusTypeNewtype
.