Add multiIndexArray builtin (CIP-0156)#7844
Conversation
32c205d to
eaeb73f
Compare
| (runCostingFunTwoArguments . paramScaleValue) | ||
| toBuiltinMeaning _semvar MultiIndexArray = | ||
| let multiIndexArrayDenotation | ||
| :: [Integer] -> SomeConstant uni (Vector a) -> BuiltinResult (Opaque val [a]) |
There was a problem hiding this comment.
- Need an explanation of why it uses Integer while indexArray uses Int
- The argument order is different from indexArray's and I see no good reason for it.
There was a problem hiding this comment.
-
indexArraytakes a scalarInt, which has a checked unlifting instance: it reads anIntegerand bounds-checks it againstInt's range, failing operationally on overflow. There's no equivalent for[Int]— list unlifting requires the element type to be inDefaultUni, andIntisn't there, onlyIntegeris (same reasonBls12_381_G1_multiScalarMultakes[Integer]). So the indices arrive as[Integer], and the0 <= i && i < lenguard does in theIntegerdomain what theIntunlifting plusVector.!?do forindexArray— additionally treating an index abovemaxBound :: Intas out-of-bounds rather than overflowing on conversion.
I added short version of this explanation as a code comment. -
The order follows CIP-0156, which specifies
forall a. List Integer -> Array a -> List a(indices first). Happy to swap toArray a -> List Integerfor consistency withindexArrayif we're ok deviating from the spec.
`multiIndexArray :: forall a. list integer -> array a -> list a` returns the array elements at the given indices in order (duplicates preserved), failing the whole call on any out-of-bounds index. Bounds are checked in the Integer domain, so an index exceeding maxBound::Int is out-of-bounds rather than wrapping. Placeholder costing (unimplementedCostingFun) until benchmarked; not exposed to Plinth. Adds the CEK denotation, flat tag, and RewriteRules/plugin exhaustiveness arms, plus regenerated type-synthesis and parser goldens. Issue: IntersectMBO/plutus-private#1675
New batch7 holds builtins that are implemented but not yet approved for release, mapped to futurePV in builtinsIntroducedIn for all three ledger languages. Per Note [Adding new builtins: protocol versions], so multiIndexArray is not available in any released protocol version. The Versions specs (and Data twin) expect it rejected at newestPV. Issue: IntersectMBO/plutus-private#1675
CEK tests covering index order, duplicate indices, polymorphic element type, empty index list, and the out-of-bounds failure modes (index == length, negative, and an index exceeding maxBound::Int). Issue: IntersectMBO/plutus-private#1675
eaeb73f to
b088b82
Compare
Adds the
multiIndexArraybuiltin from CIP-0156:forall a. list integer -> array a -> list a, returning the array elements at the given indices in index-list order (duplicates preserved) and failing the whole call on any out-of-bounds index. Bounds are checked in theIntegerdomain, so a negative index or one exceedingmaxBound::Intis out-of-bounds rather than wrapping.Placeholder costing (
unimplementedCostingFun) and gated underfuturePV, so it is not available in any released protocol version.Core language + CEK only; Plinth exposure, costing, conformance, and metatheory are separate follow-ups. Draft — not ready for review.