1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

interface A<in B> { }
 
interface B<in A> { }
 
class X : A<B<X>> { }
 
class Y : B<A<Y>> { }
 
class Test
{
	static void Main ()
	{
		A<Y> x = new X ();
	}
}

O código é um enrolado. A parte mais importante é entender interface A<in B> que é a declaração de A contravariante em B. Isso significa, a grosso modo, que A<object> instanceof A<string> == true.

A dúvida é se a atribuição A<Y> x = new X (); é válida. Vou usar <: como notação para
pode ser atribuido em, como em string <: object.

X <: A<Y> //X é uma classe e A uma interface, logo verificamos as interfaces de X
A<B<X>> <: A<Y> //Duas instâncias diferentes do mesmo tipo genérico. Por ser contravariante no primeiro parâmetro, verificamos ele
 
//Note que contravariância significa verificar na ordem inversa
Y <: B<X>  //Y é uma classe e B uma interface, logo verificamos as interfaces de Y
B<A<Y>> <: B<X> //Novamente duas instancias de um tipo contravariante, verificamos o primeiro parâmetro
 
X <: A<Y>

Calma la, voltamos a definição original! Sim, voltamos, existe um ciclo nessa verificação e ela não pode ser decidida. Tanto o compilador como o sistema de tipos são não capazes de decidir. A solução pragmática é simplesmente recusar essa atribuição.

Quem imaginaria que o novo sistema de tipos do C# possui casos que não decidíveis. Pois é, e não fica só nisso, existem outros problemas envolvendo variância como ambiguidade no caso de últimas interfaces que merecem outro artigo.

Primeiro, é necessário saber um pouco de assembly e entender como funciona a calling convention de um pc 32bit. Feito isso o próximo passo é baixar os manuais da plataforma, sejam os da Intel ou da AMD. Estou acostumado com os da Intel, inclusive tenho eles em árvore morta.

Depois disso, precisamos aprender a usar a ferramenta mais importante para quem quer se aventurar nessa área, o disassembler. No meu caso, usei o objdump da gnu. Instalei via macports no OSX é o gobjdmp por algum motivo.

São dois comandos essenciais que vamos usar, o primeiro é o “gobjdump -d” que disassembla um binário padrão da plataforma, vamos usá-lo para roubar o assembly necessário para nossa função a ser compilada. O segundo é “gobjdump -D -b binary -m i386″ que desassembla um blog binário não estruturado, essa usamos para fazer dump em arquivos do nosso código gerado e verificar seu o conteúdo.

Feito isso, compilamos o código C da nossa função e o assembly dela é algo como:

1
2
3
4
5
6
7

<_foo>:
    push   %ebp
    mov    %esp,%ebp
    sub    $0x8,%esp
    mov    $0xa,%eax
    leave  
    ret

Curto e simples, entender oque cada instrução faz deixo como exercício ao leitor porém. Para gerar essa seqüência em runtime precisamos saber como encodificar cada instrução e um manual da arquitetura é a melhor forma para tal. Por sorte não é necessário saber de nenhuma das formas avançadas de ModRM.

Mas primeiro precisamos alocar um bloco de memória no qual podemos escrever e executar. No caso de sistemas unix usamos a função mmap que permite mapear um bloco anônimo de memória [1] no processo corrente. Com C# no OSX isso é tão trivial quanto o seguinte[2]:

1
2
3
4
5
6

	[DllImport ("libc", EntryPoint="mmap")]
	public static extern IntPtr mmap (IntPtr addr, IntPtr len, int prot, int flags, uint off_t);
 
	int prot = 0x1 | 0x2 | 0x4; //PROT_READ | PROT_WRITE | PROT_EXEC
	int flag = 0x1000 | 0x0002; //MAP_ANON | MAP_PRIVATE
	var res = mmap (IntPtr.Zero, (IntPtr)4096, prot , flags, 0);

Para escrever nesse bloco de memória recém alocado usamos UnmanagedMemoryStream que é uma bela mão na roda para esses casos. Por fim, para invocarmos o código usamos outra facilidade do framework, o método Marshal.GetDelegateForFunctionPointer. Quando fiz isso em Java a alguns anos esses 3 passos foram muito mais difíceis.

Enfim, chega de enrolação, o código completo para nosso super JIT é o seguinte:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

using System;
using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;
using System.IO;
 
public delegate int NoArgsReturnInt ();
class Test {
	[DllImport ("libc", EntryPoint="mmap")]
	public static extern IntPtr mmap (IntPtr addr, IntPtr len, int prot, int flags, uint off_t);
 
	public static unsafe void Main () {
		int prot = 0x1 | 0x2 | 0x4; //PROT_READ | PROT_WRITE | PROT_EXEC
		int flag = 0x1000 | 0x0002; //MAP_ANON | MAP_PRIVATE
		var res = mmap (IntPtr.Zero, (IntPtr)4096, prot , flags, 0);
		var mem = new UnmanagedMemoryStream ((byte*)res, 4096, 4096, FileAccess.ReadWrite);
 
		//push ebp
		mem.WriteByte (0x50 + 0x05);
 
		//mov esp, ebp
		mem.WriteByte (0x89);
		mem.WriteByte (0xE5);
 
		//mov 10, eax
		mem.WriteByte (0xB8 + 0x00);
		mem.WriteByte (0x0A);
		mem.WriteByte (0x00);
		mem.WriteByte (0x00);
		mem.WriteByte (0x00);
 
		//leave
		mem.WriteByte (0xC9);
 
		//ret
		mem.WriteByte (0xC3);
 
		NoArgsReturnInt dele = (NoArgsReturnInt)Marshal.GetDelegateForFunctionPointer (res, typeof (NoArgsReturnInt));
 
		Console.WriteLine (dele ());
	}
}

Incrivelmente simples e curto. Tudo bem que não dá nem para chamar de um brinquedo, porém seu propósito é explorar os princípios básicos por traz de um JIT compiler. Um próximo passo para ele seria gerar 1 função que recebe 2 ints e os soma. Ou tornar o código
menos tosco e mais OO.

[1] mmap permite que bloco de memória seja mapeado para um arquivo
[2] Os valores de prot e flag são específicos ao OSX, então talvez não funcionem em outros derivados unix. Esses valores costumam ficar em /usr/include/sys/mman.h

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

Cada um destes valores possui um forma, que é a representação concreta para o conceito abstrato que cada um significa. Um array de bytes e uma lista de chars são duas maneiras de representar uma string – um conceito abstrato. Forma admite composição e extensão, mas isso é razoavelmente óbvio.

Por comportamento me refiro a um grupo que operações definido que operam em um dado conjunto de valores. Repetindo nosso exemplo, strings, podemos definir particionamento, remover espaços em branco e pois ai vai. Ou seja, nada mais simples que um conjunto de funções.

Por fim, taxonomia é como damos nomes a conjuntos de valores. Ruby, que usa um sistema nominal de tipos, damos um nome explicitamente a um dado conjunto de valores que irão habitar uma classe. Outro aspecto importante é que podemos usar os operadores da teoria de conjuntos para definir relações entre pares. Voltando a Ruby, a única relação é a de subconjunto, que é a herança entre duas classes.

São três elementos bem distintos, porém, linguagens OO misturam dois, as vezes mesmo todos. Por exemplo, classes são os três ao mesmo tempo, atributos a forma, métodos o comportamento e a taxonomia vem através da relação herança entre duas classes. Interfaces misturam comportamento e taxonomia. Mixins misturam forma e comportamento. O problema disso é quando você quer manipular apenas um e os outros vem de brinde.

Linguagens funcionais costumam lidar de forma mais efetiva com esse problema. Haskell separa muito bem isso, com datatypes para forma, funções lidam com o comportamento e typeclasses resolvem a questão da taxonomia. Dessa forma é possível focar apenas em um dos três sem nenhuma bagagem extra.

Um problema com haskell é que uma typeclass classifica todos habitantes de um dado tipo, não é possível fazer isso com uma parte apenas. Nesse sentido Qi possui um sistema de tipos muito interessante, baseado em sequent calculus, permitindo definir de forma mais precisa quais valores compõe um dado tipo.

Eu acredito que essa limitação da orientação a objetos é a razão pelo qual tantas pessoas preferem fugir para linguagens OO dinâmicas, que aliviam boa parte do problema dado que forma e taxonomia poder ser consideradas ad-hoc, agrada a vários, mas realmente não me agrada para construir sistema de grande escala.

A primeira solução que vem à cabeça de todos são as faculdades, afinal, uma boa graduação em ciências da computação é uma sólida fundação para um profissional da área. Devem faltar vagas ou coisa parecida, não?

Não, os números da educação superior em computação podem ser entendidos por sórdidos ou desastrosos – ao gosto do leitor. Segundo esse artigo são ofertadas todos os anos 150 mil vagas pelas faculdades. Porém apenas noventa mil se inscrevem nos processos seletivos e, pasmem, apenas 44mil se matriculam de fato em algum curso.

Não satisfeito com tal injúria, informo que apenas 17 mil destes se formam todos os anos. Assustador, no mínimo. Porém sejamos realistas, de seus colegas graduados quantos realmente ingressam na área? No meu caso, digo que esse número é próximo da metade.

Por essa análise, a cada ano o pais oferece 150mil vagas que resultarão em 8.500 novos profissionais ou, em termos relativos, uma taxa de aproveitamento de 5.6%. Pífio, péssimo, patético. Agora de quem é a culpa disso? Provavelmente minha, e sua, de todos nós. Está mais que na hora de fazermos algo pelos alumni de tecnologia deste pais.

A impossibilidade utilizar a unidade vetorial a partir de linguagens gerenciadas sempre foi uma das principais críticas dos desenvolvedores C e C++ sob a viabilidade em utilizá-las para código rico em calculo matemático. Isso agora é passado e usando mono e C# é possível gerar código com de alta performance similar ao possível com linguagens de baixo nível.

Para se ter uma ideia das possibilidades, um simples exemplo que transforma uma série de vetores com uma mesma matriz chega a ser 3x mais rápido usando Mono.Simd que o código não vetorial em C, Java ou C#. Isso sem perder as vantagens de se utilizar uma linguagem de alto nível e segura. Mas vamos ao código:

//Primeiro transformação usando ponto flutuante normal
    public static void Transform (ref Matrix matrix, ref Vector vector, ref Vector result)
    {
        result.x = vector.x * matrix.m00 + vector.y * matrix.m01 + vector.z * matrix.m02 + vector.w * matrix.m03;
        result.y = vector.x * matrix.m10 + vector.y * matrix.m11 + vector.z * matrix.m12 + vector.w * matrix.m13;
        result.z = vector.x * matrix.m20 + vector.y * matrix.m21 + vector.z * matrix.m22 + vector.w * matrix.m23;
        result.w = vector.x * matrix.m30 + vector.y * matrix.m31 + vector.z * matrix.m32 + vector.w * matrix.m33;
    }
 
//Agora usando Mono.Simd
    public static void Transform (ref Matrix4f matrix, ref Vector4f vector, ref Vector4f result)
    {
        Vector4f v = vector;
 
        Vector4f r0 = v.Shuffle (ShuffleSel.XFromX | ShuffleSel.YFromX | ShuffleSel.ZFromX | ShuffleSel.WFromX);
        Vector4f r1 = v.Shuffle (ShuffleSel.XFromY | ShuffleSel.YFromY | ShuffleSel.ZFromY | ShuffleSel.WFromY);
        Vector4f r2 = v.Shuffle (ShuffleSel.XFromZ | ShuffleSel.YFromZ | ShuffleSel.ZFromZ | ShuffleSel.WFromZ);
        Vector4f r3 = v.Shuffle (ShuffleSel.XFromW | ShuffleSel.YFromW | ShuffleSel.ZFromW | ShuffleSel.WFromW);
 
        r0 = r0 * matrix.row0;
        r1 = r1 * matrix.row1;
        r2 = r2 * matrix.row2;
        r3 = r3 * matrix.row3;
 
        result = r0 + r1 + r2 + r3;
    }

O código usando Mono.Simd fica um pouco mais complexo, principalmente até se entender como Shuffle e outros combinadores funcionam. Porém quando executado, a versão tradicional precisa executar 16 operações de multiplicação e 12 de soma contra 4 multiplicações 3 somas simd na versão vetorizada. A diferença é clara e o números também.

O release 2.2 foi o resultado de muito esforço pelo time por traz do mono e todos seus contribuidores. Esse release, porém, é especial para mim pois Mono.Simd é resultado de alguns meses de trabalho meu e fiquei muito feliz com a repercussão positiva que recebemos – vários projetos estão estudando como implementar bibliotecas de matemática vetorial usando ela.

Para quem já programou em C, ou mesmo C++, e em uma linguagem de alto nível tais quais C#, Haskell ou LISP sabe o tamanho do sofrimento que é trabalhar com uma ferramenta tão primitiva. Aos incautos não estou me referindo nem me referindo as vantagens óbvias dessas linguagens como gerenciamento automático de lixo, um sistema de tipos rico ou tipagem ou dinâmica[1].

Quando se programa próximo do metal ter um controle e visão muito clara daquilo que é gerado é muito importante, então coisas como verificações inseridas pelo compilador, não ter controle fino sobre a representação dos dados ou simplesmente não podem burlar o sistema de tipos inviabilizam o uso de uma linguagem – por mais estranho que pareça.

Entretanto usar destes argumentos para defender as relíquias que são C e C++ é temerário. Ambas linguagens foram construídas sob as bases do que era avançado em termos de compiladores nos anos 70 e para a capacidade de processamos do começo dos anos 90. Muita coisa mudou de lá para cá, menos o fato de C++ demorar horrores para compilar.

A primeira grande falha do C, e uma que chama muito a atenção, é o sistema de módulos e compilação separada. Que realmente não existe. Em ambas as linguagens se usa inclusão textual de cabeçalhos com declarações supostamente exportadas por outros módulos do sistema e pronto. O problema disso é óbvio se já tiver trabalhado em projetos grandes. O tempo de compilação individual aumenta sem razão aparente, conflitos com o nome de símbolos ocorrem e, em geral, atrapalham a vida de todos.

Continuando com a questão de processamento de texto. Macros em C provavelmente são o recurso mais importante da linguagem, aquele que a tira da lista de inúteis. É bem freqüente encontrar uma infinidade de truques feitos usando macros para sanar a falta de expressividade da linguagem. Porém tão comum quanto é encontrar gente frustada com a dificuldade de depurar um sistema rico em macros. Ao mesmo tempo, programando um dia com LISP qualquer um enxerga que um grande sistema de macros faz qualquer linguagem medíocre ir muito longe.

Por fim, minha última reclamação é devido ao fato de estar em 2009 e ainda ser obrigado a usar uma linguagem sem inferência de tipos. O artigo do Robin Milner tem quase 31 anos e ainda assim sou obrigado a pagear o compilador com aquilo que ele consegue descobrir sozinho. Inferência de tipos é um recurso ainda mais importante quando falamos de sistemas de tipos mais ricos.

Ainda assim, por algum motivo que me escapa, não existe um substituto usável para C ou C++. Talvez seja pelo fato de tal linguagem não possuir muito acadêmico em termos de papers e PHDs, ou que a enorme parte da comunidade de programadores destas linguagens é cega por achar que são o último biscoito do pacote.

[1]Ou latente, caso tenha um fetiche pelo Fowler.

O que exatamente objetos de linguagens comuns, feito C++, oferecem? Basicamente três coisas: layout, interfaces e subtipagem. Uma classe derivada define uma estrutura de dados que é uma extensão do layout daquelas de seus parentes; o mecanismo de funções virtuais é a única forma sã de se definir interfaces; e, por fim, herança é a forma de se definir uma relação de subtipagem entre dois tipos, no caso do C++ classes.

As duas primeiras propriedades são realmente úteis, a terceira é questionável – mas não vamos atentar para isso agora. Não existe uma razão óbvia para deixar extensão estrutural e interfaces atadas uma a outra. De fato, é uma enorme limitação. Java e C# possuem o mecanismo de interfaces para resolver isso, porém ambas exigem que todas sejam definidas de antemão, ou seja, são uma minúscula fração do número potencial de interfaces que suportam. Ou seja, adora um modelo de interfaces prescritivo e não latente.

Algumas linguagens funcionais resolvem este problema adotando alguma forma de tipos de alta ordem*, que permitem uma função ser definida em termos da interface exigida de um objeto e basta este atendê-la para poder ser usado, independente de herança. Pode ser visto, a grosso modo, como um mecanismo equivalente à interfaces no Java ou C# onde cada classe não precisa definir quais suportam, basta implementar os métodos relacionados.

À primeira vista, tipos de alta ordem, ou classes de tipos na terminologia e implementação do Hakell, podem parecer a mesma coisa que templates do C++, porém a semelhança fica apenas na superfície, templates são um mecanismo de macro-expansão estruturada, não existe como validar uma função em sua definição ou uso, é necessário sempre fazer sua expansão para verificar sua validade. Outra diferença gritante é a ampla possibilidade de compartilhar código entre as várias instanciações de uma função que usa tipos de alta ordem. Existe uma longa literatura sobre o assunto e várias formas de favorecer uso de memória ou performance.

Mas voltando a questão de se subtipagem é uma propriedade interessante ou não para uma linguagem ter. Bom, teoricamente é muito interessante poder definir relações de substituibilidade, mas na prática, a maioria dos frameworks não se valem de tal princípio. Um bom exemplo é o pacote de coleções do Java, ela é toda construída em termos de interfaces e herança é usada como uma forma tosca de promover reuso de código.

O súbito interesse por linguagens funcionais nesses últimos anos vem trazendo a tona uma série de avanços que estas linguagens possuem e estavam até então restritos à comunidade científica. Está mais que na hora para começarmos a repensar todos os antigo erros e quimeras que as linguagens de programação de mercado promovem e começar a pensar como produzir algo que nos permita dar o mesmo salto dos anos 60 que Algol e Fortran garantiram – e dessa vez nenhum idéia pode ser refém.

*A wikipedia, apesar de extensão não tem uma referencia para tipos de alta ordem, então vou me valer como referencia lógica de alta ordem e deixar como exercício a aplicação do mesmo para teoria de tipos. Type classes do Haskell podem ser construídas aplicando lógica de alta ordem à um sistema de tipos básico como o descrito em “Basic Simple Type Theory – Hindley, J. Roger”.

O Presidente Inácio anunciou que ela é sua favorita para 2010. A noticia é boa em um aspecto, significa ainda mais o fim da Marta – e que esta um dia explique seu envolvimento com ONGs durante sua prefeitura.

Porém como eu posso não ficar apavorado com a idéia de ter uma mulher que ficou nacionalmente conhecida pelos escândalos do dossiê dos gastos do FHC e da venda da Varig?

Vamos realmente querer essa mulher, que acredita em sacrificar inocentes* para atingir seus objetivos, como presidente? A hora de agir é essa, não podemos permitir que o Bêbado da Silva use a máquina estatal para fazer a campanha de uma assaltante.

* Ou alguém por acaso acha que o Banespa estava vazio em 1968?