Cooked.Pretty is currently a messy module. It contains helper functions, PrettyCooked instances for Plutus types, PrettyCooked instances for a few cooked types, and functions to pretty print cooked structures such as skeletons and chain state.
Problems
The module is getting too big and messy
All the instances are orphaned
Everything is mixed up
Cooked.Pretty is not a re-export module like the rest of the modules which have submodules (we have Cooked.Pretty.Class which is useful to import on its own internally in cooked)
Proposed reorganization
Cooked.Pretty re-exports the following modules
Cooked.Pretty.Options for the pretty printing options and their default value
Cooked.Pretty.Common for boilerplate helpers (itemize and enums, printing hashes, etc)
Cooked.Pretty.Class defines the PrettyCooked class and implements instances for some native Plutus types
Cooked.Pretty.Cooked implements pretty-printing for cooked structures (skeletons, chain state)
Chosen compromise about orphaned instances
According to best practices, to avoid conflicting instances, instances should be implemented either:
In the module the datatype/newtype is defined
In the module the class is defined
For Plutus types: the only possible choice is option 2. This is what is done in Cooked.Pretty.Class. Future instances for types that are defined outside cooked should go there.
For our homemade types, option 2 is not possible because it would induce a cycle in imports (e.g. between Cooked.Skeleton and Cooked.Pretty.Class). The only "good practice" solution is therefore option 1. However, we decided early on to remove all pretty-printing matter from cooked outside of the Cooked.Pretty modules. Therefore, this PR compromises by keeping orphan instances for our homemade types. For now there are only 2 of those, in Cooked.Pretty.Cooked.
Cooked.Prettyis currently a messy module. It contains helper functions,PrettyCookedinstances for Plutus types,PrettyCookedinstances for a few cooked types, and functions to pretty print cooked structures such as skeletons and chain state.Problems
Cooked.Prettyis not a re-export module like the rest of the modules which have submodules (we haveCooked.Pretty.Classwhich is useful to import on its own internally in cooked)Proposed reorganization
Cooked.Prettyre-exports the following modulesCooked.Pretty.Optionsfor the pretty printing options and their default valueCooked.Pretty.Commonfor boilerplate helpers (itemize and enums, printing hashes, etc)Cooked.Pretty.Classdefines thePrettyCookedclass and implements instances for some native Plutus typesCooked.Pretty.Cookedimplements pretty-printing for cooked structures (skeletons, chain state)Chosen compromise about orphaned instances
According to best practices, to avoid conflicting instances, instances should be implemented either:
For Plutus types: the only possible choice is option 2. This is what is done in
Cooked.Pretty.Class. Future instances for types that are defined outside cooked should go there.For our homemade types, option 2 is not possible because it would induce a cycle in imports (e.g. between
Cooked.SkeletonandCooked.Pretty.Class). The only "good practice" solution is therefore option 1. However, we decided early on to remove all pretty-printing matter from cooked outside of theCooked.Prettymodules. Therefore, this PR compromises by keeping orphan instances for our homemade types. For now there are only 2 of those, inCooked.Pretty.Cooked.