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
We claim that it's possible to extend ParamName data types with new costing parameters without issuing a new language version, however builtinsAvailableIn doesn't account for that. It's defined as
builtinsAvailableIn::PlutusLedgerLanguage->MajorProtocolVersion->Set.SetDefaultFun
builtinsAvailableIn thisLv thisPv = fold $Map.elems $Map.takeWhileAntitone builtinAvailableIn builtinsIntroducedIn
wherebuiltinAvailableIn:: (PlutusLedgerLanguage, MajorProtocolVersion) ->Bool
builtinAvailableIn (introducedInLv,introducedInPv) =-- both should be satisfied
introducedInLv <= thisLv && introducedInPv <= thisPv
which may look fine on the surface, but note how it's takeWhileAntitone and not filter or something: we can have a situation when introducedInPv <= thisPv fails, because a builtin was introduced in a late protocol version, but there's still room for a few more language versions that introduce builtins in early protocol versions. This needs fixing.
The text was updated successfully, but these errors were encountered:
We claim that it's possible to extend
ParamName
data types with new costing parameters without issuing a new language version, howeverbuiltinsAvailableIn
doesn't account for that. It's defined aswhich may look fine on the surface, but note how it's
takeWhileAntitone
and notfilter
or something: we can have a situation whenintroducedInPv <= thisPv
fails, because a builtin was introduced in a late protocol version, but there's still room for a few more language versions that introduce builtins in early protocol versions. This needs fixing.The text was updated successfully, but these errors were encountered: