Comments on: Type-classes are nothing like interfaces http://blog.tmorris.net/type-classes-are-nothing-like-interfaces/ The weblog of Tony Morris Sat, 19 May 2012 03:14:05 +0000 http://wordpress.org/?v=2.6 By: Raven http://blog.tmorris.net/type-classes-are-nothing-like-interfaces/#comment-40145 Raven Fri, 30 Apr 2010 08:07:30 +0000 http://blog.tmorris.net/?p=736#comment-40145 How about C#'s generic type constraints? Something like: public static Sort<T>(this IEnumerable<T> xs) where T : IComparable<T> { ... } notice the "IComparable<T>" as opposed to "IComparator<T>", where the objects being sorted know how to sort themselves, thus "implicit" How about C#’s generic type constraints? Something like:
public static Sort<T>(this IEnumerable<T> xs) where T : IComparable<T> { … }
notice the “IComparable<T>” as opposed to “IComparator<T>”, where the objects being sorted know how to sort themselves, thus “implicit”

]]> By: Tony Morris http://blog.tmorris.net/type-classes-are-nothing-like-interfaces/#comment-39696 Tony Morris Fri, 16 Apr 2010 00:41:04 +0000 http://blog.tmorris.net/?p=736#comment-39696 Yes Dan, this is exactly correct. <pre lang="Haskell"> newtype Product = Product Int newtype Sum = Sum Int instance Monoid Product where ... instance Monoid Sum where ... </pre> Yes Dan, this is exactly correct.

newtype Product = Product Int
newtype Sum = Sum Int
 
instance Monoid Product where
  ...
 
instance Monoid Sum where
  ...
]]> By: Dan http://blog.tmorris.net/type-classes-are-nothing-like-interfaces/#comment-39681 Dan Thu, 15 Apr 2010 16:35:41 +0000 http://blog.tmorris.net/?p=736#comment-39681 Also, for example, the Product and Sum monoids on integers? There was a good example of differentiating between the two on sigfpe a while back: [http://blog.sigfpe.com/2009/01/haskell-monoids-and-their-uses.html]. In that example, one assigns an existing class to a type class using the instance keyword. You're suggesting that one first duplicate an existing class (eg, newtype another_name_for_type = original_type) then use instance on another_name_for_type? That makes sense; it solves the explicit-implicit problem just as well. Thanks! Also, for example, the Product and Sum monoids on integers? There was a good example of differentiating between the two on sigfpe a while back: [http://blog.sigfpe.com/2009/01/haskell-monoids-and-their-uses.html].

In that example, one assigns an existing class to a type class using the instance keyword. You’re suggesting that one first duplicate an existing class (eg, newtype another_name_for_type = original_type) then use instance on another_name_for_type?

That makes sense; it solves the explicit-implicit problem just as well.

Thanks!

]]> By: Tony Morris http://blog.tmorris.net/type-classes-are-nothing-like-interfaces/#comment-39639 Tony Morris Wed, 14 Apr 2010 21:43:33 +0000 http://blog.tmorris.net/?p=736#comment-39639 Hi Dan, In Haskell it is generally considered poor form to instance a type-class more than once for a type. For example, the boolean ||/True and the &&/False monoid. It is recommended instead to "newtype" the type then instance that, requiring the user to wrap/unwrap depending which instance they'd like to use. This is quite clumsy, but I've not seen a better solution to this problem. Hi Dan,
In Haskell it is generally considered poor form to instance a type-class more than once for a type. For example, the boolean ||/True and the &&/False monoid.

It is recommended instead to “newtype” the type then instance that, requiring the user to wrap/unwrap depending which instance they’d like to use. This is quite clumsy, but I’ve not seen a better solution to this problem.

]]> By: Dan http://blog.tmorris.net/type-classes-are-nothing-like-interfaces/#comment-39636 Dan Wed, 14 Apr 2010 18:46:45 +0000 http://blog.tmorris.net/?p=736#comment-39636 Presumably, a type 'a can have more than one comparator. What is the mechanism for choosing between them? In Scala, only one implicit can be in scope else the implicit must be passed, well, explicitly. Is there something similar in Haskell? Presumably, a type ‘a can have more than one comparator. What is the mechanism for choosing between them?

In Scala, only one implicit can be in scope else the implicit must be passed, well, explicitly. Is there something similar in Haskell?

]]> By: Tony Morris http://blog.tmorris.net/type-classes-are-nothing-like-interfaces/#comment-39585 Tony Morris Tue, 13 Apr 2010 10:14:07 +0000 http://blog.tmorris.net/?p=736#comment-39585 Indeed. I have been meaning to write a post about the relationship between implicit conversion (ala Scala) and inheritance. There are some key differences between the two and especially, differences with practical implications, but there are also many insightful similarities that can be used in such a way as to say "implicit conversion is not as foreign as may seem, if you are perfectly comfortable with the idea of inheritance". I also think this is beneficial in terms of the strong aversion to syntax such as <code>A => B</code> yet there is no such aversion when the arrow is pointing upward as in inheritance (i.e. as a hint: they are the same arrow! just tilt your head 90 degrees if it helps!). This also draws on the concept of logical implication and the relationship to programming (Curry-Howard Correspondence). So many things to say :) Indeed. I have been meaning to write a post about the relationship between implicit conversion (ala Scala) and inheritance. There are some key differences between the two and especially, differences with practical implications, but there are also many insightful similarities that can be used in such a way as to say “implicit conversion is not as foreign as may seem, if you are perfectly comfortable with the idea of inheritance”.

I also think this is beneficial in terms of the strong aversion to syntax such as A => B yet there is no such aversion when the arrow is pointing upward as in inheritance (i.e. as a hint: they are the same arrow! just tilt your head 90 degrees if it helps!). This also draws on the concept of logical implication and the relationship to programming (Curry-Howard Correspondence).

So many things to say :)

]]> By: Christian Szegedy http://blog.tmorris.net/type-classes-are-nothing-like-interfaces/#comment-39565 Christian Szegedy Tue, 13 Apr 2010 00:50:26 +0000 http://blog.tmorris.net/?p=736#comment-39565 Thanks :) You also note in the last section of your post dictionary passing and implicit type conversion happens in java (to some extent) for interfaces via the inheritance mechanism. So the difference is rather that in the case of type classes you have to define the adherence to the interface at the place of the declaration of the data type, whereas in the the case of type classes it can happen more flexibly in a decoupled way (as you note it in the same section). I definitely agree with you that equating type classes to interfaces is a very bad idea from an educational point of view, since it would mainly focus on the commonalities rather than the important differences. BTW, in my view implicit conversion is really not so different from inheritance either. the main difference being the decoupled nature of declaration: if there would be a fully transitive system of implicit conversions, you could easily emulate inheritance, but not vica versa. OTOH, type classes are more restrictive than arbitrary type conversions (which is a great thing IMO), so with the same logic as this post, you could also blog "Type conversions are nothing like type classes". Whereas in my view, there is a continuum: interfaces < type classes < type conversions of increasingly flexible solutions. Thanks :)

You also note in the last section of your post dictionary passing and implicit type conversion happens in java (to some extent) for interfaces via the inheritance mechanism.

So the difference is rather that in the case of type classes you have to define the adherence to the interface at the place of the declaration of the data type, whereas in the the case of type classes it can happen more flexibly in a decoupled way (as you note it in the same section).

I definitely agree with you that equating type classes to interfaces is a very bad idea from an educational point of view, since it would mainly focus on the commonalities rather than the important differences.

BTW, in my view implicit conversion is really not so different from inheritance either. the main difference being the decoupled nature of declaration: if there would be a fully transitive system of implicit conversions, you could easily emulate inheritance, but not vica versa.

OTOH, type classes are more restrictive than arbitrary type conversions (which is a great thing IMO), so with the same logic as this post, you could also blog “Type conversions are nothing like type classes”. Whereas in my view, there is a continuum:

interfaces < type classes < type conversions

of increasingly flexible solutions.

]]> By: Tony Morris http://blog.tmorris.net/type-classes-are-nothing-like-interfaces/#comment-39461 Tony Morris Sat, 10 Apr 2010 02:10:34 +0000 http://blog.tmorris.net/?p=736#comment-39461 Christian, An essential property of type-classes is the implicit dictionary passing. In the absence of this, you have a regular data type. Interfaces do not have implicit dictionary passing and are precisely equivalent to a regular data type. Interfaces do not have the key essential property that makes type-classes distinct: implicit dictionary passing. Without implicit dictionary you have regular data types, which are exactly equivalent to interfaces. Interfaces are exactly like data types. Data types are distinguished from type-classes by virtue of the requirement for explicit passing. Type-classes have implicit dictionary passing. Without implicit dictionary passing, type-classes would be something else, such as data types. Hope that helps. Christian,
An essential property of type-classes is the implicit dictionary passing. In the absence of this, you have a regular data type. Interfaces do not have implicit dictionary passing and are precisely equivalent to a regular data type. Interfaces do not have the key essential property that makes type-classes distinct: implicit dictionary passing. Without implicit dictionary you have regular data types, which are exactly equivalent to interfaces. Interfaces are exactly like data types. Data types are distinguished from type-classes by virtue of the requirement for explicit passing. Type-classes have implicit dictionary passing. Without implicit dictionary passing, type-classes would be something else, such as data types.

Hope that helps.

]]> By: Christian Szegedy http://blog.tmorris.net/type-classes-are-nothing-like-interfaces/#comment-39449 Christian Szegedy Fri, 09 Apr 2010 17:40:56 +0000 http://blog.tmorris.net/?p=736#comment-39449 Great factual answer. Finally, you convinced me. Great factual answer. Finally, you convinced me.

]]> By: Tony Morris http://blog.tmorris.net/type-classes-are-nothing-like-interfaces/#comment-39422 Tony Morris Fri, 09 Apr 2010 02:54:40 +0000 http://blog.tmorris.net/?p=736#comment-39422 Christian, I explained exactly why type-classes are nothing like interfaces. It seems you missed it. There is no parallel to "worth noting." Christian, I explained exactly why type-classes are nothing like interfaces. It seems you missed it. There is no parallel to “worth noting.”

]]>