Imagine PMaybe - it's represented with scott encoding. As in, it is not a BuiltinData. In due time, people are going to be implementing PIsDataRepr for their custom datums and redeemers - for easier and safer matching.
What happens when they try to use PMaybe in their custom datum/redeemer?
Do we implement PIsData for PMaybe? Doesn't that mean there are now 2 Plutus Core representations for PMaybe and room for ambiguity that cannot be caught in the type system?
Do we disallow usage of PMaybe in custom datum/redeemer by not implementing PIsData? Does that mean we need another PMaybe represented purely as builtin data? Won't it be a pain to work with both if certain APIs require one and not the other? Will that mean we'll need a way to convert between the two as well?
L-as
commented
2 years ago
Imagine
PMaybe- it's represented with scott encoding. As in, it is not aBuiltinData. In due time, people are going to be implementingPIsDataReprfor their custom datums and redeemers - for easier and safer matching.What happens when they try to use
PMaybein their custom datum/redeemer?Do we implement
PIsDataforPMaybe? Doesn't that mean there are now 2 Plutus Core representations forPMaybeand room for ambiguity that cannot be caught in the type system?Do we disallow usage of
PMaybein custom datum/redeemer by not implementingPIsData? Does that mean we need anotherPMayberepresented purely as builtin data? Won't it be a pain to work with both if certain APIs require one and not the other? Will that mean we'll need a way to convert between the two as well?