Does Unison has typeclasses? Are they viable/useful in Unison?

[gerardbosch]

Hi 👋

Is there any equivalent to Haskell typeclasses or ad-hoc polymorphism in Unison?
Does this concept apply or makes sense in Unison?
What are the reasons either for providing support or not?

Thank you!!

[RolfNic]

Typeclasses themselves will likely not be implemented directly in Unison, although some equally powerful form of polymorphism will be at some point. Although they are not yet on the roadmap you can see some of the planning work in these issues: #502 and #3845

[gerardbosch]

Thanks for your answer 🙂

I'm still curious on "Does this concept apply or makes sense in Unison?".

What is the way (if there's a way) to achieve the goal that typeclasses provide (I think it's called adhoc polymorphism), right now in Unison? or are there any kind of restrictions in the language at this point? Thx again!

[chriskrycho]

Elaborating slightly on @RolfNic's answer, the FAQ has a discussion of this:

Does Unison have Haskell-style type classes?

No, or at least, not yet. We're considering our options for how to allow people to express bounded polymorphism. Seethis postfor some initial observations.

Currently there are two ideas which have been developed at least to some extent.

1. Like this: mconcat : [a] ->{Monoid a} a, where Monoid a is an ability.
2. Like this: mconcat : Monoid a -> [a] -> a, where Monoid a is a record type.

Both of these would require a set of supporting language enhancements, for example to supply the Monoid a handlers/values automatically.

That also links to this post, which has this discussion:

• What about bounded polymorphism and typeclasses? This deserves a longer post, but here are a few answers:
  • For just name overloading, Unison supports that via type-directed name resolution.
  • For effectful programming, you use algebraic effects, no need to pass dictionaries around.
  • Functions like <, ==, etc, work for any type (actually we'll probably restrict their type a bit just to keep parametricity in tact). But these are builtins, you can't implement your own (could we somehow make that possible though?).
  • The only thing that Unison has which is as general as typeclasses is explicit dictionary passing. This can sometimes be a bit tedious.
  • Typeclasses are super convenient but I don't think that as is they're a good fit for Unison, and they have problems even in the Haskell world (relevant post). Also, not for nothing: they're a pain to implement.
  • Summary: We're thinking about it. If you've got ideas, let us know!

There was an interesting discussion around typeclasses after the meetup (some folks headed over to a local pub for drinks and food). All the approaches to bounded polymorphism (typeclasses a la Haskell, modules a la ML / Scala, dictionary passing + implicit parameters, OO style subtyping ..) have strengths and weaknesses. And that's the problem: there's no approach that's a total slam dunk, which makes you think "YES, PROBLEM 100% SOLVED." Every approach has its issues. I'm hoping for some bolt of insight about this…

[pchiusano]

Also this old ticket has a bunch of discussion and ideas: #502

[gerardbosch]

Thanks Paul, @RolfNic mentioned the ticket on his answer. I still have a question, you may help clarify :) Coming from OOP/imperative, I only know the basics on FP, so,

What is the way (if there's a way) to achieve the goal that typeclasses provide (I think it's called adhoc polymorphism), right now in Unison? or are there any kind of restrictions in the language at this point?

Maybe a small example could help.

Thx again!