[Builtins] Add the 'dropList' builtin#6468
Conversation
017e9d4 to
df4dea7
Compare
df4dea7 to
7be8e1f
Compare
…to effectfully/builtins/add-dropList
7be8e1f to
e22a57b
Compare
…to effectfully/builtins/add-dropList
16db02d to
41ea9b6
Compare
| (runCostingFunOneArgument . paramNullList) | ||
|
|
||
| toBuiltinMeaning _semvar DropList = | ||
| let dropListDenotation :: Int -> SomeConstant uni [a] -> BuiltinResult (Opaque val [a]) |
There was a problem hiding this comment.
The time taken for this will probably be linear in the value (not the size!) of the first argument. That'll mean using some newtype wrapper, like this . We already have IntegerCostedLiterally, but this has an Int so that may need another wrapper.
There was a problem hiding this comment.
^ @ramsay-t FYI
but this has an
Intso that may need another wrapper.
Actually, why did I even make it Int, what's the point? Looks like a thinko.
There was a problem hiding this comment.
The time taken for this will probably be linear in the value (not the size!) of the first argument.
No, I think it's gonna be a minimum of
- linear in the value of the first argument
- linear in the length of the second argument
since drop maxBound [] equals [].
There was a problem hiding this comment.
Actually, why did I even make it
Int, what's the point? Looks like a thinko.
It's proper Integer in there now.
There was a problem hiding this comment.
No, I think it's gonna be a minimum of
linear in the value of the first argument
linear in the length of the second argument
since drop maxBound [] equals [].
I deliberately ignored that case! If we include the length of the list in the cost calculation then we'll have to traverse the entire list to measure the length when we're about to calculate the cost, and that'll slow things down. If we just base it on the number of things we want to drop then we'll still get a conservative estimate of the cost, and it'll be faster. Also, if you drop the whole of the list then you've probably done something wrong, and people probably won't submit scripts where that actually happens (or at least not often).
There was a problem hiding this comment.
Oh I see. OK, that's clever. Yeah, I think I agree, although I'd perhaps prefer to store lists together with their length, although that'd perhaps slow everything else down. Fair enough!
@ramsay-t ignore what I said and only consider the original comment in this thread.
There was a problem hiding this comment.
I'd perhaps prefer to store lists together with their length
I've wondered about doing that in the past (and maybe something similar with Data for instance), but what happens if someone lies about the length of a list in their script? Maybe that could be checked during deserialisation ...
| , headMaybe | ||
| , BI.head | ||
| , BI.tail | ||
| , BI.drop |
There was a problem hiding this comment.
Should this also go in PlutusTx.Prelude? I seem to remember that the contents of that file are kind of random though.
| chooseList (BuiltinList (_:_)) _ b2 = b2 | ||
|
|
||
| {-# OPAQUE drop #-} | ||
| drop :: Integer -> BuiltinList a -> BuiltinList a |
There was a problem hiding this comment.
Why not dropList? So that it just replaces the Haskell version with minimal effort from the user?
There was a problem hiding this comment.
For consistency, we also have head (and not headList) and tail (and not tailList) in this file.
…to effectfully/builtins/add-dropList
|
/benchmark validation |
f999164 to
e8c0b9d
Compare
|
/benchmark validation |
…s far less nice than what I had before :( )
…t' into effectfully/builtins/add-dropList
Adding `dropList` caused the `plutus-ledger-api` tests to fail. This should fix it.
Adding `dropList` caused the `plutus-ledger-api` tests to fail. This should fix it.
|
This had become very difficult to merge, so it's been closed in favour of #6817. |
This experiment adds the
dropListbuiltin so that folks can play with it. Not intended for merging.