CIP-0138 Builtin Array #6727

Unisay · 2024-12-02T13:47:49Z

Built-in Array type itself, implemented by the Data.Vector.Strict
Builtin funtion LengthArray
Builtin funtion ListToArray
Tests

The PR is ready for review but build is not working until we update flake inputs (need vector 0.13.2)

Unisay · 2024-12-02T13:50:07Z

plutus-core/cost-model/data/builtinCostModelA.json

@@ -698,6 +698,26 @@
            "type": "constant_cost"
        }
    },
+    "lengthArray" : {
+        "cpu": {
+            "arguments": 99999999999999,


Temporary value (stub)

When I was adding builtins, I was avoiding doing any of this, but maybe that was wrong, dunno. @kwxm should we add this stuff when adding a new builtin before costing is done?

@kwxm should we add this stuff when adding a new builtin before costing is done?

I think that in order to get the code to compile you have to add something here once you've added paramLengthArray here, and similarly for the other new functions. However, if you use unimplementedCostingFunction in toBuiltinMeaning then these numbers won't be used: they only come into play when you tell the denotation to run the real costing function. I'd normally add a new builtin without adding any costing code at all in order to test that it behaves as it's supposed to, and then do all of the costing at once. That's just to cut down on the initial amount of work, and because of the way all the costing code is plumbed in it's probably not obvious that you don't initially need it. The important thing is that there's no link at all between the builtin and the costing code until you put runCostingFunction<N>Arguments . param<MyNewBuiltin> in toBuiltinMeaning. Maybe we should try to make that fact clearer to implementers somewhere.

Right, doing it first time it isn't 100% clear where to draw the line, so I followed the compiler and it wanted me to fix JSON as there is TH which reads it and fails to compile if the section is missing.

plutus-core/plutus-core.cabal

plutus-core/plutus-core/src/PlutusCore/Crypto/BLS12_381/Pairing.hs

plutus-core/plutus-core/src/PlutusCore/Default/Builtins.hs

plutus-core/plutus-core/src/PlutusCore/Pretty/PrettyConst.hs

Unisay · 2024-12-02T13:58:49Z

plutus-core/cost-model/create-cost-model/BuiltinMemoryModels.hs

+  , paramLengthArray                     = Id $ ModelOneArgumentConstantCost    99
+  , paramListToArray                     = Id $ ModelOneArgumentConstantCost    99


Dummy values

@kwxm is this what should be done here before costing? Particularly given that listToArray isn't gonna be constant-cost.

@kwxm is this what should be done here before costing? Particularly given that listToArray isn't gonna be constant-cost.

Good question. I think that this doesn't really matter as long as you remember to fix it. The only time this gets used is when you run generate-cost-model, which uses this information to fill in the memory function in the JSON version of the cost model, so it has to be correct before you generate the final form of the cost model.

effectfully

Is the lack of Plinth versions of the builtins intentional?

All looks great. Kinda unfortunate that more and more is needed to add a new builtin, maybe we could automate some more. Although seems not too bad still.

effectfully · 2024-12-06T14:51:26Z

plutus-core/cost-model/create-cost-model/BuiltinMemoryModels.hs

+  , paramLengthArray                     = Id $ ModelOneArgumentConstantCost    99
+  , paramListToArray                     = Id $ ModelOneArgumentConstantCost    99


@kwxm is this what should be done here before costing? Particularly given that listToArray isn't gonna be constant-cost.

effectfully · 2024-12-06T14:52:24Z

plutus-core/cost-model/data/builtinCostModelA.json

@@ -698,6 +698,26 @@
            "type": "constant_cost"
        }
    },
+    "lengthArray" : {
+        "cpu": {
+            "arguments": 99999999999999,


When I was adding builtins, I was avoiding doing any of this, but maybe that was wrong, dunno. @kwxm should we add this stuff when adding a new builtin before costing is done?

plutus-core/plutus-core/src/Data/Vector/Orphans.hs

plutus-core/plutus-core/src/PlutusCore/Default/Builtins.hs

plutus-core/plutus-core/test/CostModelSafety/Spec.hs

effectfully · 2024-12-06T16:05:58Z

plutus-core/testlib/PlutusCore/Generators/QuickCheck/Builtin.hs

+  arbitraryBuiltin = do
+    spine <- Strict.fromLazy <$> arbitrary
+    let len = length spine
+    for spine $ \() ->


Could you define in terms of the list instance instead of the Vector one? Just arbitraryBuiltin = Strict.fromList <$> arbitraryBuiltin or something. And the same for shrink.

effectfully · 2024-12-06T16:15:13Z

plutus-core/untyped-plutus-core/test/Evaluation/Builtins/Definition.hs

+      let arrayOfInts = mkConstant @(Vector Integer) @DefaultUni () (Vector.fromList [1..10])
+      let term = apply () (tyInst () (builtin () ListToArray) integer) listOfInts
+      typecheckEvaluateCekNoEmit def defaultBuiltinCostModelForTesting term @?=
+          Right (EvaluationSuccess arrayOfInts)


Some edge cases would be nice, like an empty array etc.

You should've probably used

evals :: DefaultUni `HasTermLevel` a => a -> DefaultFun -> [Type TyName DefaultUni ()] -> [Term TyName Name DefaultUni DefaultFun ()] -> TestNested

from the below, we use it for unit tests. Not important though.

effectfully · 2024-12-06T16:34:45Z

plutus-core/untyped-plutus-core/test/Evaluation/Builtins/Definition.hs

+          term = apply () (tyInst () (builtin () LengthArray) integer) arrayOfInts
+      typecheckEvaluateCekNoEmit def defaultBuiltinCostModelForTesting term @?=
+          Right (EvaluationSuccess expectedLength)
+    , testCase "indexArray" do


We should also have some property tests, but feel free to add them in a follow-up.

plutus-tx/src/PlutusTx/Builtins/HasBuiltin.hs

Unisay · 2024-12-09T09:06:40Z

Is the lack of Plinth versions of the builtins intentional?

Yes.

…ropriate.

Unisay self-assigned this Dec 2, 2024

Unisay temporarily deployed to github-pages December 2, 2024 13:47 — with GitHub Actions Inactive