Revisit Orphan Rules #2

The original thread was closed due to inactivity.

I just wanted to bring up the following paper, which may shed some light on new approaches as well as having some coherence proofs for said approaches: Coherent Explicit Dictionary Application for Haskell: Formalisation and Coherence Proof I have not read it, am not a language expert, and have no idea how much of this could be applied to Rust.

1 Like

Haskell's type classes are very different from Rust's generics in some important details.

Haskell in general feels a lot more permissive, worryingly permissive at times, when it comes to implementing type classes for types. Meanwhile, at the same it has seemingly arbitrary limitations, for example: creating associated types or dealing with multiple typeclass constraints (the equivalent of Rust's trait bounds) is a real pain.

From what I can tell, this paper tries to bolt Coherence onto Haskell, which is a noble goal, but I don't think Rust needs that, since it was designed with coherence in mind from the ground up.

(What some people seem to be asking for at times is exactly the reduction or at least the loosening of coherence rules, and that is partially addressed by specialization. That sounds undesirable to me for reasons I'm not going to re-iterate here, but it is a significant change that has come up in the past.)

Thanks for the reply and the summary!

Although probably more of a change even from the above paper (though I'm not sure), Idris has an approach that seems to work: there are default instances for classes available in some cases, but there is a way for the programmer to specify the instance being used within a context (e.g. a particular function, iirc).

Here's what Named Implementations (basically, instances of typeclasses in Haskell-land) look like in Idris2.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.