Hacker News Reader

No, not that. I agree with you on structural typing.

What I mean is what the Scala doc calls "context bounds": http://docs.scala-lang.org/tutorials/FAQ/context-and-view-bo... (bit outdated: view bounds are deprecated)

You could think of it as "abstracting over the adapter pattern", i.e. being able to write methods that take as parameter things that can be adapted to an interface.

(And of course the main point of the Adapter pattern is retroactive implementation of interfaces.)

But, and this is important, you get to pass the actual object instead of the adapter. This matters when you need to required multiple adapters, or when you work with object equality. The object type can also flow through the type parameters (although that's sort of doable with adapters only).

Finally, because a typeclass instance is actually a single object per type satisfying an interface, you can use it for things like factory methods (what they call constructor classes in Haskell).

It's close to what I propose here: https://discuss.kotlinlang.org/t/kotlin-and-the-expression-p...

but there are differences. Scala typeclasses are based on implicits, this gives you more control to select the adapter you want depending on where the code runs. But, unlike what I propose, it's dependent on static typing, so it's not possible to select the adapter depending on the run-time type.

Right, I remember your thread, which is I guess why I'm a bit confused, as you said what you really wanted to do is make a type implement a new interface.

I do understand Haskell type classes but in a language like that, they're almost obligatory as it's not an OO language at all. But in something like Kotlin, you should need it far more rarely, so the automatic/implicit "conversion" (I realise it's not quite "conversion" in Haskell) is less vital. So some convenience for creation of adapters would seem to get you the same practical benefits in much the same way.

With respect to the difference between using a singleton vs a freshly allocated wrapper - is it really worth complicating the Java interop for what seems like an optimisation? Code that works with object identity is rare in all the code I've written and can't even be done at all in a pure functional language. And requiring multiple 'adapters', you mean interfaces I think (?) can be done already by imposing multiple generic type constraints (the where clause). The VM should be able to optimise out the overhead of the wrapper class in many cases.

That leaves implicit conversion. But Kotlin doesn't even auto-convert Int to Long. I doubt that implicit conversion will ever be a part of the language outside of a few special cases like toString().

I guess for my use cases, a wrapper class + an extension method on the existing type that adds a toFoo() is sufficient.

The point of the class instance (the "singleton") is not performance, it's that it exists independently of any instance of the type, so it can be used for factories and such.

This however, is not my main concern, and as you remarked, it does not fit very well in OO, which is why it isn't in my proposal.

On to the interesting part.

You want multiple adapters, rather than multiple interfaces, precisely because you want retroactive interface implementation. That's really the crux here. So either you pass two adapters, or you make a class combining the two adapters. I think both solution create too much bloat to be acceptable.

For me, equality isn't so rare. Both identity (==) and structural equality (equals(), done right) pop up with some regularity. Each time you use a map, for instance. And functional languages are perfectly capable of structural equality.

While Scala typeclases are implemented with implicit objects, typeclasses precisely avoid using implicit conversions. You still have the original object, the typeclasses just provides functions to work with it. It's only an implicit conversion in the same sense that passing an ArrayList to a function expecting a List is implicit conversion. This is manifest in Scala where you require a typeclass using some sort of type bound.

Thanks for the explanations. Yes, there seems to be an impedence mismatch when trying to import the concept of Haskell type classes to OOP languages.

WRT a combined adapter class, it'd look like this in Kotlin:

  class FooBarAdapter(val x: Baz, private val y = Foo(x), private val z = Bar(x)) : Foo by y, Bar by z

A bit bloaty, but still a single line of code.

(I know you already know this, I'm writing it here for Kotlin newbies).

Wow, actually this hadn't made it to my bag of trick yet.

It's very nice, though I can see that becoming quite heavyweight when you nest these calls (either heavy from the overhead, or from the syntax - at least you get to decide).

The problem there is composability. Foo and Bar might come from different libraries. Also it's very common to define one typeclass in terms of another, often several layers deep. It's easy enough to define a wrapper at an outer layer, but when you have an EitherT[WriterT[Future, MyLog, ?], MyError, MyValue] it becomes quite clunky to apply wrappers to MyLog and Future.

Both OOP and type-classes are a form of ad-hoc polymorphism, but OOP is not a replacement for type-classes. The scope overlaps and personally I find both useful, but you're making the mistake to think that type-classes are about subtyping. They are not.

Also, type-classes in Scala are not implemented by means of "implicit conversions". It has nothing to do with it. Type-classes in Scala are implemented by means of implicit parameters, also called context bounds, but that's different.

Of course, you don't really need implicit parameters to work with type-classes. That's just syntactic sugar, because you can just pass dictionaries (type-class instances) around manually.

No, the far bigger problem that Kotlin has is that it doesn't support higher-kinded types. Without higher-kinded types you can't express generic code for containers (e.g. M[T]). And without that, you can't do do type-classes and you can kiss most FP abstractions goodbye.

If you don't believe me, try coming up with an interface for things that have "map", "filter" or "flatMap.

I find typeclasses are vital when you want to give your classes secondary functionality e.g. serialization, database persistance. You need only look at the modules, mixin annotations, reflection and XML configs that Jackson or Hibernate have implemented - for good reason! - to see that traditional OO is inadequate for that kind of use case (particularly when you have a generally usable library datatype e.g. joda-time - no-one would want to have joda-time depend on Hibernate or Jackson, but at the same time the code to use it with those things should be in some library, so how do you safely connect them up?)

It's nothing like duck typing -- type classes are a major thing in Haskell, which should tell you how far from duck typing it is ;) They're also present in Scala (as the OP mentioned), in Rust as Traits, and C++11 had a proposal for Concepts, which are quite similar as well.

The short but slightly inaccurate description is that type classes are a way to allow interfaces to be implemented separately from the way you define types.

No. Structural types are called structural types. The best known typeclass implementation is that of Haskell where they're built into the language, but Scala has them as a pattern implemented with implicits; I can try to explain the concept here if you like but honestly there are probably better explanations out there.

Typeclasses are more powerful than structural types in that the implementation doesn't have to be there already (i.e. you can have an automatically resolved adapter). You might be able to hack an implementation by combining extension methods with structural types (though given the internals of how extension methods are usually implemented on the JVM I doubt it). They also allow a way to do "static virtual methods" i.e. polymorphic methods that you don't need an instance to invoke, which are used for things like Monoid#zero. Finally they provide a nicer way to express F-bounded polymorphism (i.e. the constraint on Enum or Comparable that we try to express in Java as Enum<E extends Enum<E>> or Comparable<T extends Comparable<T>>, which is clunky and doesn't actually fully constrain implementations the way it's intended to).

But both Java and Kotlin interfaces can provide default implementations. So when I say "make a class implement an interface even if it doesn't declare it as so", that included interface default methods coming along for the ride.

The best explanation of Scala type classes IMO is here:

  http://danielwestheide.com/blog/2013/02/06/the-neophytes-guide-to-scala-part-12-type-classes.html

But as you say, what Scala calls type classes are more of a pattern with some language support - you just define what is essentially an adapter, but one which is constructed/used implicitly.

Being able to write:

  interface Foo {
      val prop: String
      fun someMethod() = "we are set to $prop"
  }

and then being able to treat any Bar as Foo as long as it has some property "prop" but without regard for whether it has someMethod, sounds pretty much the same thing as Haskell/Scala's idea of type classes to me.

It's not just a default, you can provide an adapter specific to the type:

    implicit object IntMonoid extends Monoid[Int] {
      def zero = 0
      def plus(a: Int, b: Int) = a + b
    }
    implicit def endoMonoid[A] = new Monoid[A => A] {
      def zero = identity
      def plus(a: A => A, b: A => A) = a andThen b
    }

You can't do that with a default method.

While it's an excellent example, I wonder if people don't see "endoMonoid" and run away screaming.

I really wonder if people would have different reactions if this was presented as "Addable" instead.

Yeah, I wonder about calling it "addable" or "mergeable". But neither of those really captures the full generality of it - would you expect composing functions to count as "adding" or "merging"?

"Combinable"?

Integers can also be combined with other operations, like multiplication, min or max. None of those sound like "adding" or "merging" them to me.

Good point. Though a good side effect is that when you see it used that way you "a-ha!", or you figure it yourself you feel smart. Something like "endoMonoid" doesn't immediately suggest these use cases either (unless you're a math buff) but if you get to the explanation you're just left with the feeling that this is what was intended all along, not a neat breakthrough.

That's reverse API psychology for you :D

> The best known typeclass implementation is that of Haskell

Oh, I don't know about that one. In Scala type-classes are interfaces and you can put that OOP to good use. For example in the Cats library, you get an Applicative type-class inheriting from Apply, a FlatMap inheriting from Apply and a Monad inheriting from FlatMap and Applicative. By comparison in Haskell a Monad is not automatically an Applicative and you get duplicate functions with different names, duplicate code, duplicate tests, etc.

Another advantage is that in Scala type-class instances are actual values that you can pass around. And because type-class instances are actual values, along with implicits which are lexically scoped, you can always provide another instance of a type-class, depending on context. You do not have the modularity problems arising from usage of type-classes in Haskell.

"The best implementation" is entirely subjective IMHO.

EDIT: got down-votes, not complaining, but I'd like to know where I'm mistaken. Thanks.

Didn't downvote, just FYI: Haskell's Applicative is a superclass of Monad now.

Which means you are now forced to write the boilerplate

pure = return

(<*>) = liftM2 ($)

In Scala, you get it for free for any monad.

Since GHC-7.10, the minimal complete definition for a Monad instance has been (>>=) (bind) only. So you can simply move the old definition for "return" into the Applicative instance as "pure" and you're good.

He means best-known, not best known. It's a statement about which is better known, not which is better.

Oh, sorry. I'm not a native English speaker, sometimes I have parsing issues :-)

i wouldn't sweat it, there's a fair amount of ambiguity in the english grammar D:

Go's interfaces are not type-classes and type-classes aren't about structural typing.