Uma type class para os acostumados com OO pode ser vista como uma interface cuja implementações são externas aos tipos que estão atrelados. Um exemplo bem simples é Eq, que permite compar objetos do mesmo tipo:

class Eq a where
    (==), (/=) :: a -> a -> Bool
    x /= y = not (x == y)
    x == y = not (x /= y)

Para nos não iniciado em Haskell, linha um define a classe Eq e diz que ela possui um parâmetro polimófico; linha 2 diz que Eq tem 2 funções, “==” e “/=” cuja assinatura são dois valores do tipo ‘a’ e retorna um booleano; por fim, linhas 3 e 4 são implementações padrão das funções. Seria o equivalente, em pseudo-C#, ao seguinte:

interface Eq<T> {
   bool operator== (T a, T b) { return !(a != b); }
   bool operator!= (T a, T b) { return !(a == b); }
}

Uma das vantagens de type classes no Haskell é que elas podem fornecer implementações padrão para alguns de seus métodos. Bom, agora que temos Eq definida, para dizer que Listas a implementa usamos algo como:

instance Eq a => Eq [a] where
    [] == [] = True
    (x:xs) == (y:ys) = x==y && xs==ys
    _ == _ = False

Aqui vemos uma das melhores características do Haskell é explorada, que é pattern matching – e isso também é assunto para outro artigo. Como pode se notar, uma implementação de uma dada type class não está embutida na definição do tipo em questão, ou seja, não podemos interfaces como a CLR ou a JVM suportam.

A idéia é representar type classes de forma semelhante a como o ghc faz, usando dictionary passing[1], que é bem simples de entender e implementar. Para cada type class que uma função recebe nos seus parâmetros, passamos junto um objeto que representa as operações em questão. Em C# teríamos:

interface Eq<T> {
    bool op_eq (T a, T b);
    bool op_neq (T a, T b);
}
 
class Eq_Int : Eq<int> {
    public bool op_eq (int a, int b) { return a == b; }
    public bool op_eq (int a, int b) { return a != b; }
}
 
int Fun<T> (Eq<T> dict, T a, T b) {
    if (dict.op_eq (a, b))
        return 1;
    return 0;
}

Existe alguns problemas aqui, primeiro que estamos passando um parâmetro extra e segundo que não é possível eliminar a verificar por null pointer caso op_eq seja inlined. A solução é razoavelmente simples no caso do C#:

struct Eq_Int : Eq<int> {
    public bool op_eq (int a, int b) { return a == b; }
    public bool op_neq (int a, int b) { return a != b; }
}
 
int Fun<T, TD> (T a, T b) where TD: Eq<T> {
    if (default (TD).op_eq (a, b))
        return 1;
    return 0;
}

A grande mudança aqui é tornar a instância da typeclass um valuetype e construir um valor default para satisfazer o compilador. É uma pena que não podemos simplesmente chamar um método estático e TD, o que é uma limitação boba da CLR. Essa solução não é possível na JVM devido a inexistência de valuetypes e generics.

E quanto a performance dessa solução? Bom, no caso do mono, o JIT’er reconhece as chamadas como não virtuais e é capaz de fazer inline de forma bem agressiva – exatamente como desejado. Eu pensei em fazer um comparativo dessa solução com o equivalente em Java, mostrando como a CLR permite codificar tipos muito mais ricos e interessantes que a JVM – e como isso se traduz em performance. Mas realmente não estou afim de criar motivo para um flamewar por parte dos javeiros de plantão.

[1]Esse é o paper original que descreve type classes e a técnica utilizada: http://homepages.inf.ed.ac.uk/wadler/papers/class/class.ps.gz

Em Java:

int soma_array (int[] array) {
    int r = 0;
    for(int i = 0; i < array.length; ++i)
        r += array[i];
    return r;
}

Em Erlang:

soma_lista(Lista) ->
    soma_lista(Lista, 0).
 
soma_lista([H | T], Acc) ->
    soma_lista(T, H + Acc);
 
soma_lista([], Acc) ->
    Acc.

Nada de especial na versão em Java, já a versão em Erlang é bem enigmática, para a maioria quase indecifrável. O problema, talvez, seja o fato de ser uma linguagem puramente funcional, que significa, entre outras coisas, que não existe destructive assignment – não é possível alterar o valor de qualquer coisa depois de definida. Por isso que todo loop deve ser escrito usando tail recursion*.

Há quem possa achar que a sintaxe não ajuda, pois estamos usando notação própria para pattern matching e processamento de listas. Porém, como veremos, é possível reescrevê-lo removendo a sintaxe enxuta por algo mais familiar a linguagens imperativas. Para exemplificar esse processo, vou aproximar a versão Java o máximo da em Erlang e o primeiro passo é introduzir recursão.

int soma_array(int[] array) {
    return soma_array (array, 0, 0);
}
 
int soma_array(int[] array, int idx, int acc) {
    if (idx == array.length)
        return acc;
    return soma_array(array, idx + 1, acc + array[idx]);
}

Bem melhor agora! O código lembra um pouco mais a versão funcional. Porém ainda tem a diferença que Erlang usa listas encadeadas no lugar de arrays e são processadas maneira similar ao LISP, utilizando uma função que retorna o primeiro elemento e outra que retorna o resto da lista depois do primeiro. Se modificarmos o código Java para levar isso em conta, vamos ter algo que lembra muito Erlang. O código fica da seguinte forma:

interface Lista {
    int head();
    List tail();
    boolean isEmpty();
}
 
int soma_lista(Lista list) {
    return soma_array (list, 0);
}
 
int soma_lista(List list, int acc) {
    if (list.isEmpty())
        return acc;
    return soma_lista (list.tail(), acc + list.head());
}

Agora que temos uma versão do código Java com o devido processamento de listas, que tal reescrever a versão em Erlang para não usar a notação de processamento de listas e pattern matching. Com isso teremos algo que é gritantemente próximo ao exemplo anterior, como veremos a seguir:

soma_lista(Lista) ->
    soma_lista(Lista, 0).
 
soma_lista(Lista, Acc) ->
    if
        Lista == [] -> Acc;
        true -> soma_lista(tl(Lista), Acc + hd(Lista))
    end.

Agora sim, temos aquilo que meu amigo pode chamar de código decifrável. Porém não é sem abrir mão do poder da linguagem – o que é uma pena, eu diria. Um programador de Erlang provavelmente iria estranhar ver algo como escrito na última versão. Para terminar esse artigo vou mostrar como ficaria se utilizarmos as funções de acesso aleatorio a listas, algo não muito aconselhável, já que é uma operação O(N).

soma_lista(Lista) ->
    soma_lista(Lista, 1, 0).
 
soma_lista(Lista, Idx, Acc) ->
    if
        Idx > length(Lista) -> Acc;
        true -> soma_lista(Lista, Idx + 1, Acc + lists:nth(Idx, List))
    end.

*Já me descobri péssimo com tradução, por isso não me arriscarei com essa também.