Type classes vs interfaces

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:

Furthermore:

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


…hmm:

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 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 with other languages.


…existentials seem to work quite well here:

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:

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

1 Like