3 ms·
Somewhat familiar with FP and enjoy some of its benefits in my projects but I haven’t really used a full blown FP language like Haskell. What exactly is a type
by lloydatkinson 4y ago
Somewhat familiar with FP and enjoy some of its benefits in my projects but I haven’t really used a full blown FP language like Haskell. What exactly is a type class? I haven’t found an explanation that makes a lot of sense to me. I think at one time I believed them to be some kind of contract like an interface in a OO language.
Can someone explain?
- zesterer 4y agoA typeclass (or in Rust, a trait) is something that describes a set of behaviours that must be implemented by a type (in OOP languages, abstract classes are broadly equivalent). For example, the typeclass `Eq` describes how values of a type might be compared for equality. class Eq = => eq : Self -> Self -> Bool The typeclass requires that types conforming to it provide a function, `eq`, that takes two instances of itself and returns a bool (indicating whether the instances are equal). And member of this typeclass might look like: for A, B member (A, B) of Eq where A < Eq, B < Eq, = => eq = fn (a0, b0), (b0, b1) => a0 == a1 && b0 == b1 You can read this as "for any two types, A and B, a tuple of both can also be compared for equality provided both A and B can themselves be compared for equality" Typeclasses become useful because they allow you to constrain generic type parameters. For example, we can now write a function that determines whether a list contains a matching value: fn contains A : A -> [A] -> Bool where A < Eq, = | _, [] => False \ k, [x .. xs] => x == k || xs->contains(k) All of this is checked at compile-time by the compiler, ensuring that the function can only be called with types that can be compared for equality.
- lmm 4y agoOne of the things that's hard to follow is that people conflate typeclasses and typeclass instances. So, the typeclass itself is like an interface, but rather than having classes that implement that interface directly, you have typeclass instances which are like an adapter between a value (struct) and the interface - or like a virtual function table. You know how a class instance is essentially a struct + a (pointer to a) virtual function table? Imagine making those two pieces more distinct in code - the typeclass instance is the stanadlone virtual function table. So your object state is more exposed - you can't really have private fields in this paradigm since your state is just a struct value. But it's clearer what's what, and it's much easier to adapt types to interfaces even when the authors didn't know about each other, since the typeclass instance can be defined separately from both the typeclass and the value type (although there are possible inference problems with this). So lots of secondary cross-cutting functionality problems where OO languages tend to end up with an ad-hoc type registry (e.g. serialization or database mapping - just look at what projects like jackson-datatype-joda or joda-time-hibernate have to do to get themselves registered) are easier to solve in this model.