Move caseList and caseData to the end of the flat encoding
#7128
Conversation
| | DropList | ||
| -- Arrays | ||
| | LengthOfArray | ||
| | ListToArray | ||
| | IndexArray | ||
| -- Case | ||
| | CaseList |
There was a problem hiding this comment.
Does the order of constructors here matter?
There was a problem hiding this comment.
Does the order of constructors here matter?
No, I don't think so. The main thing that should never change after deployment is the flat tag. I think there are some things (tests etc) that iterate over the enumeration of all the builtins, so rearranging the constructors may alter the order that things happen in. I just moved these to the end to make them easy to find.
| LengthOfArray -> 91 | ||
| ListToArray -> 92 | ||
| IndexArray -> 93 | ||
| CaseList -> 126 |
There was a problem hiding this comment.
Is there a max bound for the tag number?
There was a problem hiding this comment.
Is there a max bound for the tag number?
Currently 127 (it uses 7 bits in the flat encoding). We've discussed what to do if we ever have more than 128 builtins and I think one possibility was to add a new AST contructor for a second lot of builtins, possibly using 8 or 9 bits to provide plenty of room. Maybe a new language version where we keep the AST the same but increase the number of bits builtins get in flat is possible as well.
Fixes https://github.com/IntersectMBO/plutus-private/issues/1613.
It seems that we may decide not to release the
caseListandcaseDatabuiltins. This PR moves them to the very end of the flat encoding (tags 126 and 127) and adjusts the tags fordropListand the array builtins (which we're definitely going to release) to fill the gap. The point of this is to make the changes as early as possible to stabilise the encoding before anything gets released and to make it easier to removecaseListandcaseDataif we decide to do so (which will involve further changes to the implementation and specification).