square a = a * a
 
square_of_sum a b = square (a + b)

Nesse exemplo, quando square_of_sum chama square, o parâmetro passado não é o resultado de a + b, mas sim algo próximo a uma closure que irá calcular a + b. Quando square for avaliada, ela precisará do valor de ‘a’, então usará a closure que recebeu como parâmetro para tal. Ou melhor, funciona quase assim, Haskell implementa um mecanismo chamado call-by-need, que resolve o valor uma única vez na primeira vez que for necessário memorizando o resultado. Isso significa que no caso de square ‘a’ será avaliada uma única vez. Por conta da memorização, não usamos o termo closure, mais sim thunk para descrever o que uma função passa para outra.

Outro detalhe importante, chamadas de função também são lazy evaluated, então tanto square, quanto square_of_sum na verdade retornam thunks para os valores em questão. Essa coisa toda pode parecer extremamente ineficiente a primeira vista e de fato é. Tanto que o GHC gera código sem uso de thunk sempre que conseguir provar que um pedaço de código pode ser strict evaluated [1].

Antes de imaginar como implementar isso em uma VM como a CLR, vamos traduzir nosso exemplo para C# [2]:

 
class Thunk<T> {
	T value;
	Func<T> closure;
	bool resolved;
 
	public Thunk (Func<T> closure) {
		this.closure = closure;
	}
 
	public T Value {
		get {
			if (!resolved) {
				value = closure ();
				resolved = true;
				closure = null;
			}
			return value;
		}
	}
}
 
Thunk<int> square (Thunk <int> a) {
	return new Thunk<int> (() => a.Value * a.Value);
}
 
Thunk<int> square_of_sum (Thunk <int> a, Thunk<int> b) {
	Thunk<int> a_plus_b = new Thunk<int> (() => a.Value + b.Value);
	return square (a_plus_b); //Já que square produz um thunk, não precisamos criar outro.
}

Bem confuso, de certo. Primeiro a implementação de Thunk, simples e direta, já square_of_sum precisa de uma variável local para ficar minimamente legível. Uma coisa é fato, C# não foi feita para ser usada com lazy evaluation.

Existe alguns problema quanto a eficiencia de fazer dessa forma. O maior deles é como lidar quando alguns valores já estão resolvidos e temos ainda assim criar um thunk para satisfazer o função chamada. A forma como GHC lida isso é passando todos parâmetros boxed de forma que é possível misturar thunks e valores sem problema. A função square, do nosso exemplo anterior ficaria assim:

 
Thunk<int> square (object a) {
	return new Thunk<int> (() => {
		int val;
		if (a is int)
			val = (int)a;
		else
			val = ((Thunk<int>)a).Value;
		return val * val;
	});
}

Outra forma de também lidar com esse problema é criar duas versões da mesma função, uma que recebe valores resolvidos e outra apenas thunks. Fazer dessa forma é vantagem quando podemos provar o uso estrito dos valores em questão. Por fim, acho que o maior problema ser achar uma forma de representar um thunk usando o mínimo possível de memória.

No nosso exemplo, em uma plataforma 32bits, Trunk usa 20 bytes, Func usa mais 40 e outros 8 da closure[3]. Ou seja, começa usando 68, coisa pacas. Podemos fazer algumas mudanças nisso. Dado que não existe null em Haskell podemos remover o atributo resolved e simplesmente verificar se closure é ou não null. Segundo, em vez criar 1 delegate toda vez podemos fazer caching dele e armazenar as variáveis capturadas no próprio thunk. Algo como:

abstract class Thunk<T> {
	public abstract T Value { get; }
}
 
class ThunkWithVars<T,V> : Thunk<T> {
	T value;
	Func<V, T> closure;
	V vars;
 
	public ThunkWithVars (Func<V,T> closure, V vars) {
		this.closure = closure;
		this.vars = vars;
	}
 
	public override T Value {
		get {
			if (closure != null) {
				value = closure (vars);
				closure = null;
				vars = default (V);
			}
			return value;
		}
	}
}
 
static Func<Thunk<int>, int> square_resolve = (a) => a.Value * a.Value;
 
Thunk<int> square (Thunk <int> a) {
	return new ThunkWithVars<int, Thunk<int>> (square_resolve, a);
}

Usando essa codificação Thunk continua usando 20 bytes porém nos livramos dos demais objetos, um ganho de 70% no final das contas. Poderíamos economizar outros 4 se juntarmos as variáveis closure e value em uma só caso T fosse do tipo referência – ou manter o resultado boxed. Mesmo sem isso, 20 bytes já é um valor razoável, conseguir o mesmo em uma JVM é basicamente impossível sem muita ginástica.

Qual a performance dessa solução? Segundo o pessoal do GHC, em média 95%-98% dos thunks gerados são resolvidos. Com um generational GC, a maioria vira lixo efêmero. Ou seja, não existe muita razão para uma VM tradicional ser mais lenta que a do GHC, o principal fator nesse caso é, sem dúvida, o compilador, que pode gerar pedaços de código inteiros sem uso de thunk.

[1] É muito comum em Haskell gerar código que não funciona sem lazy evaluation, como geradores de listas infinitas.
[2] Nesse exemplo vou trapacear e tornar as funções mono-mórficas e usar int no lugar de Number para simplificar o código.
[3] Nesse caso estou ignorando quanto de memória as variáveis capturadas usam.

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

O mais legal disso tudo é que o software é de código aberto, então qualquer um pode produzir vídeos também. Resolvi então fazer uma série deles baseados no mono. Abaixo está o primeiro deles, mostrando o moonlight. Fico devendo o áudio para o próximo.