Antes de continuar, apenas um aviso: durante o texto, utilizarei as palavras tabela e objeto intercambiavelmente. Cabe ao leitor saber que o termo técnico correto é objeto em JavaScript e tabela em Lua. Quando realmente for necessário fazer uma diferenciação, utilizarei os termos com inicial em maiúscula e em inglês.

Tabelas, arrays e objetos

Nas duas linguagens se cria um objeto vazio com {}. Além disso, por padrão, toda variável é global nas duas linguagens, a não ser que se especifique o contrário. Isso é feito através da palavra-chave local em Lua e var em JavaScript.

-- Lua
variavelGlobal = {}
local variavelLocal = {}

// Javascript
variavelGlobal = {}
var variavelLocal = {}

Criada a tabela, podemos acessar e criar novos campos através da notação de records ou de arrays:

-- Lua
a = {}
a.x = 5
a["y"] = 10

// JavaScript
a = {}
a.x = 5
a["y"] = 10

Outra forma de criar campos em um objeto é já especificá-los na sua criação. Aqui, a sintaxe muda apenas sutilmente:

-- Lua
b = { x = 5, y = 10 }

// JavaScript
b = { x: 5, y: 10 }

Por outro lado, Tables em Lua possuem algumas das características de Arrays em JavaScript. Novamente, existem diferenças sutis entre as linguagens. Primeiramente, em Lua tabelas-array são inicializadas com chaves, como qualquer Table, enquanto que em JavaScript Arrays (que herdam de Object) são inicializados com colchetes. Outra diferença é um açúcar sintático que não existe (que eu saiba) em JavaScript, mas que existe em Lua e que nos permite já criar um campo na sua inicialização. Por fim, talvez a diferença mais chata seja que arrays em Lua são indexados a partir de 1. Sabendo disso, podemos enumerar os dias da semana e definir que dia é hoje da seguinte forma:

-- Lua
semana = { "Domingo", "Segunda", "Terça", "Quarta", "Quinta", "Sexta", "Sábado"; hoje = "Sábado" }

// JavaScript
semana = [ "Domingo", "Segunda", "Terça", "Quarta", "Quinta", "Sexta", "Sábado" ]
semana.hoje = "Sábado"

Nas duas linguagens, podemos escolher iterar apenas na parte array ou iterar por todos os campos do objeto. Isso é feito da seguinte forma:

-- Lua: apenas array
for i, v in ipairs(semana) do
    print(i, v)
end

-- Lua: tudo
for i, v in pairs(semana) do
    print(i, v)
end

// JavaScript: apenas array
for(var i = 0 ; i < semana.length; i++) {
    console.log(i + "\t" + semana[i])
}

// JavaScript: tudo
for(var i in semana) {
    console.log(i + "\t" + semana[i])
}

Metatabelas e Protótipos

Aqui, o como-fazer começa a se diferenciar entre as duas linguagens; por isso, tratá-las-ei separadamente, começando pelo JavaScript. No entanto, o como-funciona guarda muitas semelhanças, que irei resgatar quando chegar à explicação sobre Lua.

Em JavaScript, se quisermos alterar o estado de um objeto através de um método, usamos a palavra-chave this.

var obj = { value: 0, inc: function () { this.value += 1 } }
obj.inc()

No entanto, a notação para se criar um novo objeto usando chaves funciona bem quando se está criando um singleton. Quando se quer um objeto que servirá de base para outros, de forma similar a uma classe, o melhor é usar a notação abaixo.

// JavaScript
function Shape(color) {
    this.color = color || "none"
    this.printColor = function () { console.log(this.color) }
}

var s1 = new Shape()
var s2 = new Shape("red")
s2.printColor()

Feito isso, se quisermos criar uma nova classe que herda comportamento da classe Shape, usamos a palavra prototype.

// JavaScript
function Square(color, size) {
    this.color = color || "none"
    this.size = size || 1
    this.getArea = function () { return this.size * this.size }
}
Square.prototype = new Shape()
var s = new Square("blue", 5)
s.getArea()
s.printColor()

O que está acontecendo aqui? Embora não tenha sido definida uma função printColor na classe Square, uma função é chamada, e, curiosamente, essa função faz exatamente o que se esperava que fizesse. A mágica está no uso de prototype – quando o interpretador do JavaScript percebe que não existe um campo (seja ele uma variável ou uma função) em um objeto, ele procura em seu protótipo. Se essa variável não for encontrada no protótipo, ela será procurada no protótipo do protótipo. Esse processo continuará indefinidamente até que a variável efetivamente seja encontrada ou até que não existam mais protótipos onde se procurar.

// JavaScript
function WeightedSquare(color, size, weight) {
    this.color = color || "none"
    this.size = size || 1
    this.weight = weight || 0
    this.getWeight = function () { return this.weight }
}
WeightedSquare.prototype = new Square()
w = new WeightedSquare("green", 3, 2)
w.getArea()
w.printColor()

O problema desse modo de orientação a objetos é que ele não cria um encapsulamento das variáveis. Assim, w.color = "purple" funcionará perfeitamente.

Em Lua, podemos fazer as mesmas coisas de modo similar. No entanto, como Tables são abstrações mais genéricas que Objects (já que, por exemplo, podem cumprir o papel de um Array também), às vezes precisamos de um ou dois passos a mais.

Criar um singleton pode ser feito de forma muito similar, com a diferença de que a referência a si mesmo é explícita em Lua, e se chama self em vez de this. Há, no entanto, um açúcar sintático para isso, também mostrado abaixo.

-- Lua
obj = { value = 0, inc = function (self) self.value = self.value + 1 end }
obj.inc(obj)

-- Lua com açúcar sintático
obj = { value = 0 }
function obj:inc() self.value = self.value + 1 end
obj:inc()

Novamente, se quisermos usar um objeto como base para outros objetos, precisaremos de uma outra notação. Aqui também já aparece o primeiro uso da ideia de metatabelas e metamétodos. Assim como Tables são mais genéricas que Objects, Metatables são mais genéricas que Prototypes. Por um lado, isso significa que usar Tables e Metatables como Objects e Prototypes dá um pouco mais de trabalho; por outro, isso significa que Tables e Metatables têm mais casos de uso (embora não serão mostrados aqui).

-- Lua
Shape = { color = "none" }
function Shape:new(o)
    o = o or {}
    setmetatable(o, self)
    self.__index = self
    return o
end

function Shape:printColor() print(self.color) end

local s1 = Shape:new()
local s2 = Shape:new({ color = "red" })

s2:printColor()

Como isso funciona? Primeiro, é criada uma Table que servirá de base para os objetos da classe Shape. Depois, é criado um novo método, chamado new, que usa uma Table passada como argumento como base ou cria uma nova. Esse método também estabelece que a metatabela desse objeto o é a classe Shape e que o metamétodo __index dessa metatabela é a própria classe Shape. O papel desse metamétodo __index é ditar o que acontece quando se tenta acessar um índice inexistente; se for utilizada uma tabela em vez de uma função, o interpretador procurará a variável que não foi encontrada nessa tabela.

Portanto, quando é chamado o método s2:printColor(), o interpretador percebe que não há nenhum campo na tabela s2 com esse nome; então ele procura na metatabela associada a ela a definição de __index para saber o que fazer. Ele encontra a definição, que diz que o interpretador deve continuar procurando na tabela Shape (que era o self quando Shape:new foi chamado) e finalmente encontra o que estava procurando.

Percebe-se que esse processo é muito similar ao que acontece quando chamamos um método que não existe em um Object em JavaScript, mas que existe em seu Prototype. A grande diferença é que esse processo já se inicia logo na primeira classe do processo, e não somente quando começamos a usar herança.

-- Lua
Square = { size = 1 }
setmetatable(Square, Shape)
function Square:new(o)
    o = o or {}
    setmetatable(o, self)
    self.__index = self
    return o
end
function Square:getArea() return self.size * self.size end
s = Square:new({color = "red", size = 5})

A herança em si não acrescenta nada de novo, exceto que, assim como protótipos em JavaScript, o processo de busca por uma variável pode continuar a busca na metatabela da metatabela e assim sucessivamente.

-- Lua
WeightedSquare = { weight = 0 }
setmetatable(WeightedSquare, Square)
function WeightedSquare:new(o)
    o = o or {}
    setmetatable(o, self)
    self.__index = self
    return o
end
function WeightedSquare:getWeight() return self.weight end
w = WeightedSquare:new({ color = "green" })
w:printColor()

Novamente, o problema desse método é que ele não cria um encapsulamento. Podemos, assim como em JavaScript, alterar w.color = "purple" sem problemas.

No entanto, diferentemente do que acontece com JavaScript, é possível criar um sistema de herança múltipla em Lua. Basta que o metamétodo __index seja efetivamente uma função, em vez de uma tabela, e que essa função percorra uma tabela de tabelas procurando uma que contenha o método necessário. Exemplo de classes que façam isso ficam como exercício para o leitor (ou então leiam o capítulo 16.3 de Programando em Lua).

Encapsulamento

Antes de começarmos com o encapsulamento, vejamos que ambas linguagens suportam closures:

-- Lua
function makeInc(init, step)
    local state = init or 0
    local inc = step or 1
    return function()
        state = state + inc
        return state
    end
end

//JavaScript
function makeInc(init, step) {
    var state = init || 0
    var inc = step || 1
    return function () {
        state = state + inc
        return state
    }
}

Em JavaScript, o uso de closures mais o uso de singletons dá origem ao Module Pattern. Esse padrão pode ser facilmente traduzido para Lua.

-- Lua
function newAccount (initialBalance)
    local self = {balance = initialBalance}

    local withdraw = function (v)
                         self.balance = self.balance - v
                     end

    local deposit = function (v)
                        self.balance = self.balance + v
                    end

    local getBalance = function () return self.balance end

    return {
        withdraw = withdraw,
        deposit = deposit,
        getBalance = getBalance
    }
end

// JavaScript
function newAccount(initialBalance) {

    return {
        withdraw: withdraw,
        deposit: deposit,
        getBalance: getBalance
}

(Exemplo retirado do capítulo 16.4 do livro Programming in Lua). A diferença de se usar esse padrão em Lua é que, apesar de estarmos lidando com objetos com estado, esse estado está contido na closure, e não mais sendo passado como argumento. Portanto, para chamar esses métodos usamos ponto e não dois-pontos.

The nice thing about standards is that you have so many to choose from. – Andy Tanenbaum

Anarquia

De maneira geral, o ecossistema do software livre é anárquico. Falo isso não como crítica ­– tampouco como elogio –, mas sim como um fato. Como exemplo, veja os gerenciadores de pacotes: cada um com seu formato de arquivo e sua(s) interface(s) (gráfica ou não), cada qual com suas nomenclaturas e padronizações. Isso acontece quando a “comunidade” não consegue escolher um campeão e a utilização de um ou de outro torna-se uma questão de gosto.

Esse é um caso extremo, onde vários programas de funções similares disputam entre si o cinturão de Melhor Gerenciador de Pacotes™, e não há a menor interoperabilidade entre eles. Claro, existem ferramentas que convertem um .deb em um .rpm, mas esses programas só tiram proveito do fato que dois pacotes para um mesmo programa terão de armazenar de alguma forma os mesmos arquivos e metadados. À parte da conversão, um gerenciador funciona sem levar em consideração a existência de outros gerenciadores – ele não tentará descobrir se tal pacote está instalado naquele sistema, a não ser que ele mesmo o tenha instalado. Por isso, ter um sistema que conte com dois ou mais gerenciadores de pacote é pedir por problemas.

Mas nem sempre as coisas precisam ser assim complicadas…

Meritocracia

Às vezes aparece um campeão. Até a chegada do Chrome, o Firefox carregava o cinturão de Melhor Navegador Livre™. Isso não significa que não existiam alternativas, apenas que entre Konqueror, Epiphany e lynx, o Firefox era o favorito de nove entre dez pessoas.

Mas nem sempre as coisas são assim simples…

Diplomacia

Outra possibilidade é o surgimento de um protocolo de interoperabilidade. Não existe órgão capaz de verificar e obrigar todo desenvolvedor a seguir esses padrões, mas quando os padrões são sensatos, sua desobediência faz com que os usuários do programa infrator o olhem torto.

Talvez um dos melhores exemplos disso seja a variável XDG_CONFIG_HOME, que diz onde arquivos de configuração devem ser criados. Por padrão, essa variável tem como valor ~/.config e é aí que todos os programas deveriam criar seus arquivos de configuração. Quando algum programa não segue esse padrão, os usuários xingam muito no Twitter e na mailing list do projeto.

Mas nem sempre a vida é assim bela… Quando surge um padrão que não é bem aceito, o problema não é resolvido e continuamos na anarquia.

Notificações

Notificações deveriam ser um caso de diplomacia. Estabelecido o padrão de que a forma de comunicação entre processos é usando o d-bus (dando fim ao dcop utilizado pelo KDE), bastava apenas criar uma API padrão para a exibição de notificações. Essa API foi criada e, pasme, bem aceita. Sendo assim, agora eu posso criar um programa que use notificações (um gerenciador de Downloads que avise quando terminou de baixar seus pacotes, por exemplo) e ele irá exibir as notificações padrões do ambiente em que está, seja no KDE, no Gnome ou numa casinha de sapê.

Bem, talvez eu tenha faltado com a verdade quando disse que a API fora bem aceita. Visando ser a Apple do software livre, a Canonical achou por bem desenvolver um outro daemon de notificações, para unificar a experiência entre os desktops. Afinal, <sarcasmo>o Gnome, o KDE e o XFCE são tão parecidos, só faltava isso mesmo</sarcasmo>.

Superficialmente, esse novo daemon segue a API criada; porém, alguns parâmetros são ignorados. Por quê? Porque os desenvolvedores da Canonical se acham mais espertos que você, e que o controle deve ficar nas mãos deles. Se escrevi um pequeno verificador para minha caixa de entrada, qual o problema de que a duração da notificação seja de apenas um segundo? É mais do que suficiente para que eu possa reconhecer o ícone e saber do que se trata. No entanto, a Canonical acha melhor ignorar o parâmetro que determina o tempo de duração de uma notificação e usar um tempo absurdamente grande para esse tipo de notificação.

A solução? Um patch que acrescenta doze linhas ao código original. Não dói aplicá-lo e recompilar o programa, mas é um incômodo saber que esse problema poderia estar resolvido há dois anos.

A eventual chegada do padrão C++0x promete resolver esse problema, finalmente trazendo as funções lambda à linguagem. No entanto, isso se refere somente ao C++; mesmo o vindouro padrão C1X não faz referência a uma eventual chegada da ferramenta ao bom e velho C.

Porém, se seu projeto só será compilado usando o compilador GNU, uma boa parte de seus problemas pode ser resolvida com a utilização de um macro e de duas extensões. O uso dessas extensões significa que seu código deixará de seguir o padrão ISO e, portanto, deixará de ser portável. Se isso é um problema ou não, você que deverá julgar.

Comecemos pelo macro:

#define lambda(return_type, args_and_body) \
    ({                                     \
        return_type __fn__ args_and_body   \
        &__fn__;                           \
    })

Pouco da mágica realmente acontece nele, ele serve apenas para facilitar um pouco nosso trabalho. Abaixo, um exemplo de como chamá-lo e no que ele se expande:

int (*max)(int, int) = lambda(int, (int a, int b) {
         return a > b ? a : b;
    });

int (*max)(int, int) = ({
    int __fn__ (int a, int b) {
        return a > b ? a : b;
    }
    &__fn__;
    });

Analisando o código de cima para baixo, encontramos o par de caracteres ({, fechado na última linha do código por seu inverso, }). Isso faz parte da primeira extensão usada, Statements and Declarations in Expressions. Com ela, podemos criar um novo escopo, da forma similar ao que acontece quando usamos { }, com a diferença de que o último statement será usado como valor de retorno (apesar de não usarmos a palavra-chave return).

Logo em seguida, vemos a definição de uma função, chamada __fn__, de tipo return_type e definida por args_and_body. No entanto, só podemos defini-la aí por causa da segunda extensão utilizada, Nested Functions. Com essa extensão, podemos definir funções dentro de outras funções, funções dentro de ifs, dentro de expressões compostas (como neste caso) etc.

Juntando tudo, o que estamos fazendo é definindo uma nova função, __fn__, que tem como escopo apenas um pequeno bloco e retornando seu endereço com &__fn__.

Porém, esta solução não “captura” as variáveis num escopo léxico (não cria uma closure), o que pode trazer alguns problemas. Por exemplo, o código abaixo funciona sem problemas, já que a função lambda é executada enquanto a variável soma ainda está dentro de seu escopo.

#include <stdio.h>
#define lambda(return_type, body_and_args) \
    ({                                     \
        return_type __fn__ body_and_args   \
            &__fn__;                       \
    })

void map(int array[], int n, int (*fn)(int)) {
    int i;
    for(i = 0; i < n; i++)
        array[i] = (*fn)(array[i]);
}

int main() {
    int array[] = {1, 2, 3, 4};
    int soma = 0;

    map(array, 4, lambda(int, (int x) {
                soma += x;
                return x;
            }));
    printf("%d\n", soma);

    return 0;
}

Por outro lado, a função abaixo não funcionará:

#include <stdio.h>
#define lambda(return_type, body_and_args) \
    ({                                     \
        return_type __fn__ body_and_args   \
            &__fn__;                       \
    })

int (*adder(int what))(int) {
    return lambda(int, (int x) {
            int __inc = what;
            return x + __inc;
        });
}

int main() {
    int (*inc1)(int) = adder(1);
    printf("%d\n", inc1(1));
    printf("%d\n", inc1(1));
    return 0;
}

Quando inc1 é chamada, adder já terminou de ser executada e what não está mais em escopo. O resultado, portanto, é indefinido. Aqui, a primeira chamada funciona normalmente, mas a segunda causa uma segmentation fault.

Na lista de discussão comp.lang.c (segundo link das fontes), há uma outra forma de se tentar fazer isso (SPOILER: que também não funciona).

Fontes:
lambdas-in-c
Lambda’s in GCC

#!/usr/bin/env python2

import dbus
import dbus.service
from dbus.mainloop.glib import DBusGMainLoop
import gobject

class Greeter(dbus.service.Object):
    def __init__(self, Name=""):
        bus_name = dbus.service.BusName('org.local.greeter',\
                                            bus=dbus.SessionBus())
        dbus.service.Object.__init__(self, bus_name, '/%s' % Name)

    @dbus.service.method('org.local.greeter')
    def hello(self, Name="world"):
        print "Hello, %s!" % Name
        return "Hello, %s!" % Name 

DBusGMainLoop(set_as_default=True)
myGreeters = [Greeter("A"), Greeter("B")]

myLoop = gobject.MainLoop()

try:
    myLoop.run()
except KeyboardInterrupt:
    myLoop.quit()
    print "Bye!"

Começamos o arquivo importando os módulo necessários. Em vez de importar o módulo gobject, alguns tutoriais usam o módulo gtk. A função dos dois será a mesma: implementar o loop principal do serviço (tanto que o loop principal do gtk é implementado sobre o loop principal do gobject, apenas com alguns tratadores a mais). Como não iremos usar nenhum componente gráfico neste exemplo, não há a necessidade de se usar o gtk.

Em seguida criamos a classe que implementará o serviço, a classe Greeter. No construtor (__init__), definimos o nome do serviço — no caso, org.local.greeter —, e dizemos que ele é um Session Bus em vez de um System Bus (este reservado para serviços de mais baixo nível, como o HAL e o NetworkManager. No construtor também iniciamos o objeto, informando o nome que definimos anteriormente e lhe dando um caminho (path). O caminho é útil em casos onde se que o mesmo serviço dê acesso a vários objetos parecidos — por exemplo, o Emacs poderia dar acesso via D-Bus a cada um de seus buffers através do caminho /Emacs/Buffers/<Nome do Buffer>.

Depois, definimos um método. Note a presença do decorador (@dbus.service.method('org.local.greeter')). De certa forma, esse decorador estabelece que o método a seguir é “público”, ou seja, que pode ser acessado por processos externos. Para termos uma melhor organização do código, podemos criar outros métodos que não queremos que sejam acessíveis externamente; nesses casos, basta não usar o decorador. O método em si é bastante simples: ele imprime uma mensagem no terminal em que o serviço estiver rodando e retorna para o processo que o chamou essa mesma mensagem. Na prática, geralmente desejaremos que o serviço retorne alguma coisa em vez de imprimir, mas deixei assim para mostrar que existem as duas possibilidades.

Então temos o código para fazer o serviço executar. Criamos um novo DBusGMainLoop e o definimos como Loop padrão. Seguindo a documentação, atualmente não faz sentido criar mais de um loop, já que ainda não há suporte para isso (ao menos não no Python). Na linha seguinte são criados dois objetos da classe Greeter, cada um com um path diferente, /A e /B; fiz assim para demonstrar como isso é utilizado. E então criamos o loop principal e o executamos.

Do lado do cliente — no caso, o Emacs —, o código fica:

(require 'dbus)
(dbus-list-known-names :session)
(dbus-call-method :session "org.local.greeter"
                           "/A"
                           "org.local.greeter"
                           "hello"
                           "Emacs")

Caso se queira chamar o objeto /B, basta trocar o path na função dbus-call-methor.

Comparado ao COM do Windows, eu considero o D-Bus mais “limpo”. Mesmo quando se implementa um serviço COM em Python, sempre fico com a impressão de que certas coisas poderiam ser abstraídas de maneira melhor (CLSIDs, por exemplo).

Ainda assim, embora o D-Bus seja uma alternativa à altura (ou até melhor) que o COM, ele não substitui o DCOM. Nada impede que a comunicação entre processos seja feita entre diferentes máquinas, o problema é que, ao menos por enquanto, o D-Bus não implementa nenhum sistema de segurança — tanto de autenticação de usuário como de criptografia de dados.

Fonte

1² = 1 + 2.0 = 1
2² = 2 + 2.1 = 4
3² = 3 + 2(2+1) = 9
4² = 4 + 2(3+2+1) = 16
5² = 5 + 2(4+3+2+1) = 25
…

ou, genericamente:

A primeira coisa que me perguntei foi se isso é válido para qualquer n. Fiz um programa rapidinho em Haskell para calcular para mim:

square :: Integer -> Integer
square x = x + (2 * (foldl (+) 0 [1..(x-1)]))

test :: [Integer] -> Bool
test [] = True
test (x:xs) = if (square x) == (x*x)
              then test xs
                   else False

Testei de 1 a algum número bem grande. 100k ou 1M, não me lembro bem. O resultado foi True, significando que a equação é válida para pelo menos um número grande de ns. Ainda assim, fica a pergunta: é válida para qualquer n? E, a questão fundamental, por quê?

A prova por indução nos garante que sim, essa equação é válida para qualquer n, e também dá uma ideia de porque é válida. Se alguém conseguir fazer uma figura com a interpretação geométrica desse resultado, seria interessante.

[1] Sim, ela ainda existe e é bastante ativa.

Exatamente, são os números de Fibonacci. Claro que essa tabela de conversão não é exata, mas é uma aproximação muito boa ao resultado correto. No entanto, não há surpresa nenhuma; se calcularmos a razão entre dois números de Fibonacci consecutivos, teremos , sendo a proporção áurea. Por acaso, esse valor é muito próximo à relação entre milhas (terrestres) e quilômetros; uma milha é igual a 1,609344 quilômetros.

Aos iniciados nas artes da informática, essa “confusão” da imprensa tem uma desgostosa sensação de déjà vù. Com o início da propagação dos computadores pessoais, surgiram os hackers. Em inglês, o sufixo -er significa ”aquele que faz”, semelhante ao nosso “-eiro”: sapateiro, costureiro, … Já hack nada mais é que a nossa velha conhecida gambiarra. O motivo pelo qual hoje associamos a palavra hacker a malfeitores virtuais foi justamente a incompetência, ou talvez malícia, da mídia, que usava essa inocente palavra “aquele-que-faz-gambiarras” como sinônimo para ”aquele-que-quebra”, os crackers. Hoje em dia, corrigiu-se o problema usando a terminologia “white hat” e “black hat”. Os hackers bonzinhos são os de chapéu branco e os malvados são os de chapéu preto. Claro que na vida nada é tão simples assim e existem os “grey hats”, “red hats”, “blue hats”, “polka-dot hats”, …

Confusão similar faz a Folha ao usar o mesmo termo para designar quem infringe direitos autorais e hackers, seja lá qual for a cor de seu chapéu. É importante que o nome “pirata” esteja o mais livre possível de preconceitos em uma época em que o Partido Pirata sueco chegou ao parlamento e que o embrião de um partido pirata brasileiro começa a se formar. Mais importante ainda se nos lembrarmos de que o que está em jogo não é apenas o direito ou não de se baixar arquivos da internet, mas também uma legislação que englobe e entenda a Internet. Segundo a constituição brasileira, por exemplo, qualquer cidadão tem direito de se expressar livremente, salvo em anonimato (artigo 5º, inciso IV); uma demonstração de que mesmo algumas das leis básicas não são válidas na rede.

A Folha, ao tratar ambos como a mesma coisa, confunde e desinforma ao invés de cumprir seu papel como fonte de informação.

Um dos sites mais úteis que existem é o Gerador de Lero-lero. Não tenho certeza se o algoritmo usado é um Gerador de Markov mesmo, mas se não for, a idéia é bem parecida.

Gerador de Markov é um programa que analisa um texto procurando as combinações de palavras mais comuns e então gera um texto usando as mesmas combinações em um texto que é estatisticamente similar ao anterior. Como essa análise será feita depende da implementação. Eu escolhi usar combinações de 3 palavras, ou seja, uma palavra do texto gerado depende das duas anteriores a ela. Variando a quantidade de palavras usadas em cada combinação, altera-se o texto resultante: se eu escolhesse combinações de uma palavra, o texto gerado seria completamente aleatório, se eu escolhesse combinações de dez palavras, o texto resultante ficaria mais parecido com o original.

A implementação de um Gerador é relativamente simples, clique em “Ler o resto do artigo” para ter acesso ao código em Common Lisp. O código está bem dividido e cada função tem uma função clara (evidentemente).

Primeiramente, criamos uma hash-table que conterá as combinações de palavras. Usamos uma hash-table por ela ser mais eficiente. Se usássemos listas ou árvores, teríamos de fazer buscas toda vez que o Gerador fosse adicionar uma nova palavra ao texto. Logo no começo também, inicializamos o gerador de números aleatórios.

Para que possamos analisar as combinações de palavras, precisamos primeiro dividir a string em uma lista de strings. A função “space-position” se ocupa de descobrir onde fica o próximo “divisor de palavras”, ou seja, um espaço, um tab ou uma quebra de linha. O que vier antes será o delimitador. Se houver vários espaços em sequência, nós teríamos uma lista com algumas strings vazias, mas o “cond” na função “split-string” detecta isso com “(= pos 0)” e evita que isso aconteça.

Logo em seguida vem algumas funções auxiliares. “Last-two” retorna os dois últimos elementos de uma lista qualquer. Precisaremos dela mais tarde. “Random-elt” e “random-key” retornam um elemento aleatório de uma lista e uma chave aleatória de uma hash-table respectivamente. “List-triples” retorna os trios que podem ser formados de uma lista. Note que ela não gera todos os arranjos possíveis, apenas as combinações sequenciais. Imagine que existe um bloco com espaço para três “coisas”. Esse bloco percorre a lista sequencialmente gerando os trios. Assim, a lista ‘(1 2 3 4 5) seria percorrida como: ‘((1 2 3) 4 5), ‘(1 (2 3 4) 5) e ‘(1 2 (3 4 5)). Portanto, (list->triples ‘(1 2 3 4 5)) retornaria ‘((1 2 3) (2 3 4) (3 4 5)). “String->symbol” retorna um símbolo com o mesmo nome que o conteúdo da string passada como argumento. Não me pergunte porque eu preferi usar símbolos ao invés de strings mesmo. Talvez o gerador ficaria melhor assim, já que ele saberia diferenciar quando uma palavra está iniciando uma frase pela letra maiúscula, ou talvez isso não mudasse lá grande coisa.

“Insert-triple-into-table” é a função que faz o trabalho sujo: ela é a responsável por inserir os trios gerados por “list->triples” na hash-table que críamos no começo do programa. Ela é feia, não é uma função que me orgulho de ter escrito, mas ela funciona. Perceba que cada entrada na hash-table inicial é, por sua vez, outra hash-table. Essa segunda hash-table guarda uma lista com as possíveis palavras que podem ser usadas.

“Insert-string-into-table” organiza o trabalho de separar uma string em uma lista de strings, transformá-las em símbolos, gerar os trios e inserí-los na hash-table.

“Insert-file-into-table” foi uma função que deu trabalho escrever. Inicialmente, ela seria a função responsável por abrir um arquivo, salvá-lo como uma string e então passar para “insert-string-into-table”. Porém, a forma com que fiz isso era péssima, o consumo de memória ia para as alturas e o tempo de execução também. Em uma das tentativas, reimplementei boa parte da “insert-string-into-table” em “insert-file-into-table”, mas acabei deixando as duas funções mesmo assim, já que as duas são úteis. Depois, consegui implementar esta função segundo a idéia original com um desempenho muito melhor.

Finalmente, a parte interessante: “generate” gera um texto com no máximo o número específicado de palavras. Não há garantias de que ele gerará o número máximo, já que algumas combinações podem fazer com que ele não consiga gerar mais nada.

Só para me exibir, resolvi colocar alguns trechos que o Gerador criou tendo como base o texto deste artigo (um artigo recursivo):

“logo no começo também, inicializamos o gerador de markov mesmo, mas se não for, a idéia é bem parecida.”

“gerador de markov é um gerador de markov”

“se houver vários espaços em sequência, nãs teríamos uma lista e uma chave aleatória de uma lista e uma chave aleatória de uma lista com algumas strings vazias, mas o “cond” na função “split-string” detecta isso”

Eu o tenho usado nas conversas de MSN com sucesso. Ele detecta que a outra pessoa falou “oi :)” e gera o texto “olá =]” ou variação. Depois ele detecta a combinação “tudo bom?” e responde “sim, e contigo?”. Depois ele passa o comando para mim. OK, isso não é sério… ainda. Preciso aprender a fazer plugins para o Pidgin ainda (o bitlbee seria mais interessante nesse aspecto).

(defparameter *table* (make-hash-table))
(setq *random-state* (make-random-state t)) ; Random seed

(defun space-position (string)
  "Finds the position of a 'space' character in a string. By 'space' I mean a
newline, space or tab character."
  (let ((sp (position #\Space string))
        (nlp (position #\Newline string))
        (tp (position #\Tab string)))
    (let ((values-list (remove-if #'null (list sp nlp tp))))
      (if values-list
          (apply #'min values-list)
          nil))))

(defun split-string (string)
  "Splits a string into a list of strings use spaces as delimeters."
  (let ((pos (or (space-position string) -1)))
    (cond ((= pos -1) (list string))
          ((= pos 0)  (split-string (subseq string (1+ pos))))
          (t (append (list (subseq string 0 pos))
                     (split-string (subseq string (+ pos 1))))))))

(defun last-two (list)
  "Returns the last two elements from a list."
  (let ((l (length list)))
    (if (> l 1)
        (list (nth (- l 2) list) (nth (- l 1) list))
        nil)))

(defun random-elt (list)
  "Returns a random element from a list"
  (let ((l (length list)))
    (if (= l 0)
        nil
        (nth (random (length list)) list))))

(defun random-key (table)
  "Returns a random key from table"
  (random-elt (loop for key being the hash-keys of table collect key)))

(defun list->triples (list)
  "Returns sequencial triples from a list."
  (if (< (length list) 3)
      nil
      (append (list (list (nth 0 list) (nth 1 list) (nth 2 list)))
              (list->triples (cdr list)))))

(defun string->symbol (string)
  "Convert a string into a symbol"
  (intern (string-upcase string)))

(defun insert-triple-into-table (triple)
  "Insert a triple of symbols in the table"
  (if (hash-table-p (gethash (first triple) *table*))
      (progn
        (setf (gethash (second triple) (gethash (first triple) *table*))
              (push (third triple) (gethash (second triple) (gethash (first triple) *table*)))))
      (progn
        (setf (gethash (first triple) *table*) (make-hash-table))
        (setf (gethash (second triple) (gethash (first triple) *table*))
              (list (third triple))))))

(defun insert-string-into-table (string)
  "Inserts the string into a hash table."
  (mapcar #'insert-triple-into-table
          (list->triples (mapcar #'string->symbol (split-string string)))))

(defun insert-file-into-table (filename)
  (let ((str ""))
    (with-open-file (f filename :direction :input)
      (loop for line = (read-line f nil 'eof) until (eq line 'eof)
         do (setq str (concatenate 'string str '(#\newline) line))))
    (insert-string-into-table str)))

(defun generate (words)
  "Generate a text with 'words' words."
  (let* ((first-word (random-key *table*))
         (second-word (random-key (gethash first-word *table*)))
         (text (list second-word first-word))) ;;; This list will be reversed
    (dotimes (i words)
      (let ((first-table (gethash (second text) *table*)))
        (if (hash-table-p first-table)
            (push (random-elt (gethash (first text) first-table)) text))))
    (format t "~(~{~a ~}~)" (reverse text))))

Programas em Haskell são preguiçosos. Isso significa que quando uma variável é definida, ela só será computada quando seu valor for necessário. Assim, se fizermos um programa similar ao de baixo, fatorial de 1000 nunca será calculado, já que o seu valor não é necessário para calcular 1+1.

x = factorial 1000
putStrLn $ show (1+1)

Extrapolando essa mesma ideia* para outras definições, podemos definir uma lista de infinitos uns:

uns = repeat 1

Ou então com todos os números naturais:

naturais = [1..]

Com um pouco mais de perspicácia, é possível criar listas contendo todos os números de Fibonacci, ou então todos os fatoriais:

fibs = 1:1: (zipWith (+) fibs (tail fibs))
facs = 1:(zipWith (*) facs [1..])

Se quisermos 10 elementos de cada, fazemos:

dezFibs = take 10 fibs
dezFacs = take 10 facs

Essa implementação é bastante eficiente : se precisamos do fatorial de 10 e logo em seguida o de 11, não precisamos calcular 11×10×9×…×1, basta calcular 11×10!, que já havia sido computado. Melhor ainda : se uma hora precisarmos do fatorial de 7, ele já estará calculado, pronto para ser utilizado.

Agora sim a parte interessante, em que C entra nessa história. Embora minha implementação não seja nem de longe tão interessante como a utilizada pelo Haskell, ela serve de base para mostrar como uma implementação de stream ou listas infinitas pode ser feita em C.

A grande diferença entre listas e streams é que não trabalharemos com a idéia de um ponteiro para o próximo elemento, mas sim com uma expressão que ao ser executada nos dará o próximo elemento. Ou seja, ao invés de um ponteiro para outro elemento do mesmo tipo, nós temos um ponteiro para uma função.

typedef struct {
    int i;
    int (*cont)(int);
} stream;

Isso altera a forma como acessamos o próximo elemento. Não podemos mais utilizar o famoso ptr = ptr->prox porque estaremos apontando para uma função. Por isso, abstraí o processo de chamar a função com o valor da stream em uma função chamada proximo, que retorna uma nova struct com seu valor i atualizado pela função cont, o que dá a impressão de que avançamos na lista.

stream proximo(stream inicio)
{
    stream tmp;

    tmp.i = (*inicio.cont)(inicio.i);
    tmp.cont = inicio.cont;

    return(tmp);
}

Para exemplificar o uso de streams, criei a função pega que é similar à função take no Haskell, mas que no caso não retorna os valores, só os imprime.

void pega(int elementos, stream inicio)
{
    int i;
    stream atual = inicio;

    for(i = 0; i < elementos; i++)
    {
        printf("%d\n",atual.i);
        atual = proximo(atual);
    }
    printf(".\n.\n.\n\n");
}

Por fim, criei duas streams e duas funções auxiliares (que falta fazem expressões lambda). O código completo se encontra abaixo:

#include <stdlib.h>
#include <stdio.h>

typedef struct {
    int i;
    int (*cont)(int);
} stream;

stream proximo(stream inicio)
{
    stream tmp;

    tmp.i = (*inicio.cont)(inicio.i);
    tmp.cont = inicio.cont;

    return(tmp);
}

int soma_um(int i)
{
    return(i+1);
}

int repete(int i)
{
    return(i);
}

void pega(int elementos, stream inicio)
{
    int i;
    stream atual = inicio;

    for(i = 0; i < elementos; i++)
    {
        printf("%d\n",atual.i);
        atual = proximo(atual);
    }
    printf(".\n.\n.\n\n");
}       

int main(int argc, char *argv[])
{
    stream naturais, identidade;

    naturais.i = 1;
    naturais.cont = &soma_um;

    identidade.i = 1;
    identidade.cont = &repete;

    pega(10, naturais);
    pega(10, identidade);
    return 0;
}

*eu escrevi “idéia” mas aparentemente os verificadores ortográficos já aderiram todos às novas regras ortográficas… fica assim mesmo.

Enfim, comecemos pela forma mais simples de armazenar séries de dados na memória, arrays, seguiremos para listas, árvores, e então chegaremos às hash tables. Se tudo que você quer é um exemplo de implementação, vá ao fim do artigo.

Arrays

Internamente, quando se declara um array, um bloco de memória contínuo é alocado. Isso significa que elementos de um array estão sempre próximos entre si e que percorrer todo um array é relativamente rápido. O ponto fraco dos arrays é não serem flexíveis: Um array de tamanho 5 tem tamanho 5 e pronto, acabou. É possível criar um array b com tamanho 6 e copiar os 5 primeiros elementos de a para b, mas o array a continua tendo tamanho 5. No entanto, se esse tipo de operação começa a se tornar frequente demais, a vantagem de performance do array começa a desaparecer.

Primeiro, é necessário alocar o novo array e copiar os elementos. Depois, é necessário limpar o array anterior, ou daremos início a um gasto desnecessário de memória.

Com o problema da flexibilidade em mente [1], foi criado um novo método para lidar com séries de dados, as listas ligadas/linkadas.

Listas

Listas ligadas recebem esse nome porque cada nó (node) se liga a outro. Existem algumas formas diferentes de se implementar isso, como:

• Cada elemento aponta para o próximo. O último aponta para NULL. É assim que funcionam as cons cells em Lisp, Haskell e aposto que em várias outras linguagens.
• Cada elemento aponta para o próximo e o anterior. Isso facilita algumas operações, mas complica outras. Há um aumento no consumo de memória também, já que são necessários dois ponteiros.

Existem outras formas, assim como variações dessas. Lembre-se que há sempre uma troca entre consumo de memória e eficiência no processamento. Existem formas de usar listas que apontam para o próximo elemento e para o anterior usando apenas um ponteiro, mas para isso é necessária uma operação a mais (XOR).

Um detalhe sobre listas: geralmente os novos elementos dela são “empurrados” (push) no começo da lista, ao invés de adicionados (append) ao fim da mesma. O código fica muito mais rápido assim, já que não é necessário percorrer toda a lista para adicionar um novo elemento.

Existem também as árvores binárias, que estruturalmente são parecidas com listas, mas que apresentam outras vantagens e desvantagens.

Árvores binárias

Árvores binárias facilitam muito nas buscas: Se a condição c for verdadeira, siga à esquerda, senão, siga à direita. Isso significa que mesmo em árvores muito grandes, o número de “passos” dados é relativamente pequeno. Para se ter uma idéia, em uma árvore com 100.000 elementos, no máximo 17 “passos” terão de ser dados (). No entanto, para que isso seja verdade, a árvore tem de estar bem equilibrada (tanto o lado esquerdo como o direito terem o mesmo número de níveis). Existem algoritmos para isso, mas não entrarei nesses detalhes.

Toda essa agilidade em buscas vem com um preço: a inclusão de novos elementos em uma árvore é mais próxima da função append em uma lista que um push. Apesar de não ser necessário atravessar a árvore toda, ainda é necessário fazer comparações e tomar decisões a partir daí. Além disso, árvores consomem um pouco mais de memória, já que são necessários dois ponteiros (esquerda e direita) ao invés de só um (próximo) como geralmente é o caso em listas.

Por fim, existem as hash tables, que mistura arrays com listas e tem bom desempenho em buscas.

Hash tables

Hash tables são arrays de pequenas listas. No entanto, esse array não é acessado sequencialmente. Para ficar mais claro, vou começar com a função que dá nome a esse método: a função de hash.

Função hash
Esta função tem por objetivo associar um número a uma “coisa”. No exemplo que darei mais a diante, a função hash associa um número a uma pessoa a partir de seu nome. É esse número que nos dirá em que posição do array a “coisa” será armazenada; por isso, é preciso levar duas coisas em consideração: seu tempo de execução, já que ela será executada na adição de novos elementos e na busca por elementos já existentes, e a probabilidade de ela gerar o mesmo número para representar objetos diferentes.

Colisões
Se por um acaso a função hash gerar o mesmo número n para dois elementos, o programa não travará, nem o elemento anterior será apagado. O que ocorrerá é que a posição n deixará de conter unicamente um elemento, agora ela contém uma pequena lista de dois elementos.

Por que todo esse alarde sobre funções hash que gerem números diferentes? Pelo simples fato de que se você incluiu 10 elementos em um array com 10 posições, era de se esperar que em geral cada posição tivesse apenas um elemento. No entanto, com uma função hash ruim, pode acontecer de uma única posição ter, por exemplo, oito elementos. Analisando a performance deste caso, parece muito mais uma lista que uma hash table.

Lembre-se de que a função hash não pode ser aleatória ou depender do tempo, por exemplo, ou você não irá encontrar o elemento na hora de fazer uma busca!

O Array
O número de colisões entre os números não depende exclusivamente da função hash. É evidente que se o programa for salvar 1000 elementos em um array de 10 posições, haverá várias colisões. Pelo outro lado, salvar 10 elementos em um array de 1000 posições é um desperdício enorme de memória.

O código

Creio que o código esteja bastante claro, mas qualquer coisa perguntem. Se vocês quiserem “ver” um caso de colisão, troque o 5 na linha #define REGISTROS 5 por 4.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

/* Define o numero de posicoes no array. Note que esse nao eh o limite maximo */
#define REGISTROS 5

/* Abstracao de uma pessoa. Apenas para exemplo. */
typedef struct Pessoa Pessoa;
struct Pessoa {
    char *nome;
    char *profissao;
    unsigned short idade;
    unsigned short senha;
    Pessoa *proxima;
};

/* Onde os registros serao salvos */
Pessoa *pessoas[REGISTROS];

unsigned int hash(const char *nome);
unsigned int registrar_pessoa(Pessoa *p);
Pessoa *achar_pessoa(const char *nome);

int main(int argc, char *argv[])
{
    /* Exemplos */
    Pessoa joao = { "Joao Ninguem", "Bohemio", 21, 6969, NULL };
    Pessoa jose = { "Jose Pessoa",  "Nerd", 12, 1234, NULL };
    
    
    registrar_pessoa(&joao);
    registrar_pessoa(&jose);

    achar_pessoa("Joao Ninguem");
    achar_pessoa("Jose Pessoa");
    achar_pessoa("Maria Pessoa");

    return 0;
}

/* Dado um nome, retorna um numero no intervalo [0,REGISTROS[ */
unsigned int hash(const char *nome)
{
    char *p = nome;
    unsigned int soma = 0;

    while(*p != 0) /* caractere nulo indica fim da string */
    {
        soma += *p;
        p++;
    }
    
    return(soma % REGISTROS);
}

/* Registra uma pessoa no array */
unsigned int registrar_pessoa(Pessoa *p)
{
    unsigned int posicao;
    if(p == NULL)
        exit(1);

    posicao = hash(p->nome);
    
    /* Posicao vazia, basta incluir a pessoa aqui */
    if(pessoas[posicao] == NULL)
    {
        pessoas[posicao] = p;
    }

    /* Houve uma colisao entre as posicoes, devemos usar o campo "proxima" */
    else
    {
        Pessoa *tmp = pessoas[posicao];
        while(tmp->proxima != NULL) tmp = tmp->proxima;
        tmp->proxima= p;
    }

    printf("registrado em %u.\n", posicao);
    return(posicao);
}    

Pessoa *achar_pessoa(const char *nome)
{
    unsigned int posicao = hash(nome);
    Pessoa *p = pessoas[posicao];

    for(; p!=NULL ; p = p->proxima)
    {
        /* Nome foi encontrado */
        if(strcmp(p->nome, nome) == 0)
        {
            printf("pessoa encontrada em %u.\n", posicao);
            return(p);
        }
    }

    /* Se a funcao chegar aqui, o loop terminou sem encontrar a pessoa, entao
     * ela nao existe */
    printf("pessoa nao encontrada.\n");
    return(NULL);
}

[1] Não tenho certeza se historicamente os arrays se desenvolveram antes das listas, eu creio que sim.