# Type classes vs interfaces

**URL:** <https://discourse.haskell.org/t/type-classes-vs-interfaces/7323>\
**Category:** Uncategorized\
**Created:** [August 16, 2023, 7:38am UTC](https://discourse.haskell.org/t/type-classes-vs-interfaces/7323 "2023-08-16T07:38:12Z")\
**Posts on this page:** 1\
**Showing post:** 32

<div class="post-metadata">

**Author:** ![atravers](https://avatars.discourse-cdn.com/v4/letter/a/45deac/32.png) [@atravers](https://discourse.haskell.org/u/atravers)\
**Post date:** [August 17, 2023, 12:02pm UTC](https://discourse.haskell.org/t/type-classes-vs-interfaces/7323/32 "2023-08-17T12:02:00Z")

</div>

> [@graninas](#):
>
> […] a runtime semantics an interface mechanism should have.

Are there any existing specification/s of _“interface-centric”_ semantics available? (They don’t have to be yours.)

> Type classes basically can’t do this. They simply don’t have [what’s required.]

As I vaguely recall, type classes were introduced to allow overloading of identifiers. While there have been attempts to extend them into supporting (variants or features of) object orientation, overloading is still their primary use. And since they’re a language feature, this observation applies:

> [@maxigit](#):
>
> If it’s built in the language, then it is usually less verbose and there is usually one prefered way of doing it.

Furthermore:

> [@](#):
>
> When it is not, there is usually some boiler plate and different schools of how to do it […]

…along with the use of extensions like free or existential types.

* * *

> [@graninas](#):
>
> My general advice to all Haskellers is to practice [using] more languages, OOP included, and broaden their horizons. The notion of a programming interface is super important.

…hmm:

- 

> [@](#):
>
> The essential difficulty with this approach is that since the monad is hardcoded into the function’s type signature, it also gets hardcoded into clients who wish to call that function.
> 
> [The trouble with monads](https://fexpr.blogspot.com/2011/12/trouble-with-monads.html) (2011)

- 

> [@graninas](#):
>
> I want to encapsulate the result completely so that the client code could work with it abstractly, and I don’t really want to carry all those type-level bits here and there (because it breaks the encapsulation and brings a lot of boilerplate).

**If** I’m understanding that correctly…right now, that could only be achieved by making Haskell’s regular function type `(->)` more _“permissive”_, much like that of Standard ML or OCaml: languages where all those type-level bits don’t have to be carried throughout your programs. Those observations by @maxigit apply here too:

- The [purity](https://web.archive.org/web/20221204080950/https://www.maynoothuniversity.ie/mathematics-and-statistics/undergraduate-studies/why-do-research-pure-mathematics) of Haskell’s function type is at the cost of effects;

- Allowing direct effects for the corresponding type in SML or OCaml is at the cost of purity.

This is another reason why I’m interested in that specification: it’s then much easier to see _objectively_ what Haskell lacks, instead of trying to rely on _subjective_ [personal experience](https://stats.libretexts.org/Bookshelves/Introductory_Statistics/Inferential_Statistics_and_Probability_-_A_Holistic_Approach_(Geraghty)/01:_Introduction/1.02:_The_Blind_Man_and_the_Elephant) with other languages.

* * *

> [@graninas](#):
>
> Existentials do something, but yet, it is a crutch that doesn’t work as needed

…existentials seem to work quite well here:

- [State in Haskell](https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.52.3656&rep=rep1&type=pdf)

And that confinement of mutable state (and the associated side-effects!) to otherwise-regular (pure) Haskell definitions alleviates the need to need to carry those particular type-level bits around! Then there’s the classic:

- [Abstract Types Have Existential Type](https://theory.stanford.edu/~jcm/papers/mitch-plotkin-88.pdf)

Perhaps it can help explain why existential types have been mentioned so often in this context.

---

_[View the full topic](https://discourse.haskell.org/t/type-classes-vs-interfaces/7323)._