Edit Question - KnowledgeHub

Title Body

Basic question: what design principles should one follow when choosing between using a class or using a record (with polymorphic fields) ? First, we know that classes and records are essentially equivalent (since in Core, classes get desugared to dictionaries, which are just records). Nevertheless, there are differences: classes are passed implicitly, records must be explicit. Looking a little deeper, classes are really useful when: we have many different representations of 'the same thing', and in actual usage, which representation is used can be inferred. Classes are awkward when we have (up to parametric polymorphism) only one representation of our data, but we have multiple instances. This leads to the syntactic noise of having to use newtype to add extra tags (which exist only in our code, as we know such tags get erased at run time) if we don't want to turn on all sorts of troublesome extensions (i.e. overlapping and/or undecidable instances). Of course, things get muddier: what if I want to have constraints on my types? Let's pick a real example: class (Bounded i, Enum i) => Partition a i where index :: a -> i I could just as easily have done data Partition a i = Partition { index :: a -> i} But now I've lost my constraints, and I will have to add them to specific functions instead. Are there design guidelines that would help me out?

Tags (comma-separated) Cancel