-
-
Notifications
You must be signed in to change notification settings - Fork 131
Description
What is your idea? Provide a use case.
Inspired by the optimization done by @MicroProofs in Bullet, it seems like a low-hanging fruit to auto-convert to integers any sum types that none of their constructors hold values.
As an example, if a datum carries a boolean, its False (or True, not sure which has index 0 😅) is encoded as d87980 in CBOR. This can be reduced by 2 bytes to a simple 00 in CBOR to represent the index without the overhead.
Why is it a good idea?
Currently data encoding of sum types translate to the Constr variant of Data, which carries an index, and a list of data values:
data Data
= Constr Integer [Data]
| Map [(Data, Data)]
| List [Data]
| Int Integer
| B ByteStringThis list is always empty for constructors without values (e.g. True and False of Bool). So this empty list becomes an unused overhead.
By having the compiler auto-convert such sum types, we get to drop the empty list and reduce on-chain data bloat.
What is the current alternative and why is it not good enough?
Using builtin.unconstr_index gives a cheap access to the index of a Constr (as implemented here in Bullet). However, this can reduce maintainability of the code as the compiler won't be able to catch changes to the underlying sum type.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status