You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is currently not possible to construct pairs of values of arbitrary built-in types, only (Data, Data). This means that a lot of things that could be represented as pairs, list of pairs, list of pairs of lists etc currently have to go through either Data or SOPs. In particular, Value is a map from CurrencySymbol to a map from TokenName to Integer, i.e. could be represented as [(ByteString, [(ByteString, Integer)])].
So given that both the specification and the formalization support mkPair in principle, we should perhaps allow it in the implementation as well (see this on why we can't add mkPair right away). The way to support it is to introduce the # kind like the specification and the formalization do. I'm not really sure how that is supposed to be reflected in Plinth though.
But on the other hand... why not just use SOPs? I guess, because certain toolchains like Aiken don't bother themselves with SOPs? Maybe we want to respect that, maybe they should add some support for SOPs, dunno.
The text was updated successfully, but these errors were encountered:
It is currently not possible to construct pairs of values of arbitrary built-in types, only
(Data, Data)
. This means that a lot of things that could be represented as pairs, list of pairs, list of pairs of lists etc currently have to go through eitherData
or SOPs. In particular,Value
is a map fromCurrencySymbol
to a map fromTokenName
toInteger
, i.e. could be represented as[(ByteString, [(ByteString, Integer)])]
.So given that both the specification and the formalization support
mkPair
in principle, we should perhaps allow it in the implementation as well (see this on why we can't addmkPair
right away). The way to support it is to introduce the#
kind like the specification and the formalization do. I'm not really sure how that is supposed to be reflected in Plinth though.But on the other hand... why not just use SOPs? I guess, because certain toolchains like Aiken don't bother themselves with SOPs? Maybe we want to respect that, maybe they should add some support for SOPs, dunno.
The text was updated successfully, but these errors were encountered: