I'm not too happy with the `Castable` constraint, and I already have ideas for how to get rid of it. But maybe we should do it in a follow-up to this main body of UTXO-HD work.
The idea is to not parameterise LedgerTables by the ledger state type l but by the block type blk. Castable is currently capturing the fact that key/value types are the same regardless of whether l ~ LedgerState blk, or l ~ ExtLedgerState blk, or l ~ Ticked (LedgerState blk). This is true for all block types:
type instance Key (LedgerTables l) = Key l
type instance Value (LedgerTables l) = Value l
type instance Key (Ticked1 l) = Key l
type instance Value (Ticked1 l) = Value l
The reason I did not implement this change initially is that I trouble fitting this into the code, because some parts are blissfully unaware of the fact that a type parameter l, representing (ticked/extended) ledger states, always has a blk type parameter in practice. It would be a largish refactoring to make code aware of the blk parameter where necessary.
The idea is to not parameterise
LedgerTablesby the ledger state typelbut by the block typeblk.Castableis currently capturing the fact that key/value types are the same regardless of whetherl ~ LedgerState blk, orl ~ ExtLedgerState blk, orl ~ Ticked (LedgerState blk). This is true for all block types:The reason I did not implement this change initially is that I trouble fitting this into the code, because some parts are blissfully unaware of the fact that a type parameter
l, representing (ticked/extended) ledger states, always has ablktype parameter in practice. It would be a largish refactoring to make code aware of theblkparameter where necessary._Originally posted by @jorisdral in https://github.com/IntersectMBO/ouroboros-consensus/pull/1267#discussion_r1825719546_