CIP-0138 array

[Unisay]

Closes ##6731

[ana-pantilie]

This doesn't implement the builtin functions, right? It just defines them and the compiler recognizes them as builtins, but the evaluator doesn't yet know how to evaluate them. I assume that will be done in a separate commit/PR.

[ana-pantilie]

Why do the elements inside the array have I constructors, while the integer argument to indexArray (2) doesn't?

[Unisay]

Idk, looks like a pretty-printing issue to me

[kwxm]

I think there's definitely something wrong there. The UPLC syntax is completely wrong. It should be something like

(program 1.1.0 [[(force (builtin indexArray) (con (array integer) [1,2,3])] (con integer 2)])`

Oh, wait. Maybe it's an array of data, in which case it should be

(program 1.1.0 [[(force (builtin indexArray) (con (array data) [I 1,I 2, I 3])] (con integer 2)])`

(maybe I haven't got the brackets exactly right).

[Unisay]

We looked at this example with @bezirg and came to the conclusion that you're expecting "Classical" representation, while golden file uses "Readable" one.

[kwxm]

while golden file uses "Readable" one.

Why though? I think all (?) of the other UPLC golden files in the repository are in "Classical" form. It's not that important though.

[zliu41]

New parameters must be appended, not inserted in the middle.

And these names don't seem accurate - e.g., ListToArray is linear, so there needs to be an intercept and a slope. If they aren't accurate, then I'm not sure what the point is adding them at all. @kwxm What do you think?

[zliu41]

Also these need to be added to V1 and V2 as well.

[Unisay]

New parameters must be appended, not inserted in the middle.

👍🏼 I wrote a golden test which will fail if this condition is violated

And these names don't seem accurate - e.g., ListToArray is linear, so there needs to be an intercept and a slope. If they aren't accurate, then I'm not sure what the point is adding them at all.

The point is to make build green. Some parameters have to be added, otherwise CI tests fail.

[zliu41]

I wrote a golden test which will fail if this condition is violated

How do we update the golden file when new parameters are added?

The point is to make build green. Some parameters have to be added, otherwise CI tests fail.

I'll let @kwxm check whether this is the right thing to do.

[Unisay]

How do we update the golden file when new parameters are added?

cabal test plutus-ledger-api-test fails if new parameter names were inserted in the middle, not appended.
cabal test plutus-ledger-api-test --test-options --accept updates the golden file.

[kwxm]

The easiest thing to do would have been to update plutus-tx and plutus-tx-plugin and deal with plutus-ledger-api in a separate PR after the costing gets done. I think it'd all get through CI in that case, although I might be wrong.

[kwxm]

The point is to make build green. Some parameters have to be added, otherwise CI tests fail.

Is that true? If you put new things in futurePV then I think they're not tested. Maybe I'm missing something though: it's difficult to remember how all this works without going through the whole process of adding something.

[kwxm]

The sutff for plutus-tx and plutus-tx-plugin all looks OK (although I think there is a problem with the UPLC syntax in some of the golden tests: I'm not sure why that is becuase it's OK elsewhere). However I'd recommend not committing all of the changes to plutus-ledger-api: I think it's enough to add the new builtins to futurePV and leave everything else unchanged (but stash the updated tests somewhere in case we any them later!). It's not really meaningful to extend the cost model parameters until we know what they're going to be, so it's probably simpler to leave them unchaged for now. We also have to do expModInteger, caseList and caseData as well as the array builtins, and it'd probably be best to do everything at once when all of the costing is finished.

[kwxm]

Note that there' an issue to update these tests. They got a bit broken when we made the interface more general for Conway. Maybe this is a good start!

[kwxm]

We'll probably have to modify all of this anyway for the next HF, since the cost model will have got bigger again for that. The new bitwise builtins and I think also ripemd_160 should certainly be in it, and maybe some of the other new ones as well.