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.

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.

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

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?

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.

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.

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