Looks interesting, but if I'm understanding correctly, this OO type
class pattern is already widely used in Java/C# class libraries [1, 2].
The main thrust of the paper is then pointing out the connections of
this pattern to type classes, and how to extend this pattern with
implicit instantiation to encompass Haskell's implicit type class
resolution. It took me a couple of reads to understand these two points.
C# suffers from a similar problem as Haskell here, re: numerous
sort/sortBy and equals overloads for
IComparable<T>/delegate/IComparer<T> instances. They've tried to
mitigate this to some extent in recent releases by providing standard
factory methods which perform runtime type tests on the type parameters
and cache the resulting instances in static fields .
They then provide two overloads, one with an explicit
IEqualityComparer<T> param, and one without that uses the implicit
equality comparer obtained via EqualityComparer<T>.Default. This is
obviously just a pattern to overcome the absence of implicits.
However, while reading this paper I remembered that C# 4.0 is getting
named and optional parameters with default values. Assuming default
values could be specified using general static terms, ie. access static
fields/properties or invoke static methods, we get some of the power of
implicits. Only one overload would then be needed, with the default
value being the term: EqualityComparer<T>.Default
Unfortunately, default parameters are currently limited to constants
, since they are embedded as attribute metadata. Named params with
default values could generalize explicit type class instances by making
all instances explicit, and specifying a standard path-dependent type as
a default. There is quite a bit of hand-waving going on here of course,
so take with a grain of salt.
On 26/03/2010 4:33 AM, Bruno Oliveira wrote:
> Adriaan Moors, Martin Odersky and I finally managed to submit the paper
> that we have been working on. I think this is of interest to the
> discussion, so here is a link to it:
> A quick comment below, but I am still not entirelly freed from the paper.
> Still have a couple of hours to try to spot typos :).
bitc-dev mailing list