Computaria - assuntos computacionais por Jefferson Quesado

Implementando uma pilha a partir de uma fila

Tue, 19 May 2026 00:00:00 +0000

Em uma conversa despretenciosa com o Leandro Proença no LinkedIn, mencionei que dá pra implementar pilha usando apenas uma fila.

Bem, vamos fazer isso? Primeiro, vamos definir exatamente o que é “implementar uma estrutura X com uma estrutura Y”, então vamos pro caso mais trivial que é implementar uma fila usando duas pilhas, então vamos implementar uma pilha usando apenas uma fila.

Nota importante aqui, muitos desses resultados e das estratégias usadas são decorrentes de conversas que já tivemos aqui no Computaria, como por exemplo:

Definindo pilhas e filas

Já definimos antes essas estruturas, né? Como em Criando filas e pilhas “apenas” com funções em java, mas ali tinha algumas limitações diferentes (como a questão dos efeitos colaterais) que me levaram a decisões de design… diferentes… do que se encontraria em um código Java selvagem em seu habitat natural.

No caso, aqui vamos usar algo mais parecido com as estruturas de dados que foram usadas para percorrer os grafos em Meu take sobre o algoritmo de Dijkstra:

push(element: T) => void
pop() => T
empty() => boolean

Aqui tanto pilha como fila vão seguir esse mesmo shape: um container que eu posso inserir objetos, recuperar objetos de lá de dentro e verificar se está vazio.

Uma fila com duas pilhas

Bem, aqui a implementação básica é a pilha, então vou precisar instanciar ela. Vou fazer de modo bem simples: um ArrayList que eu insiro e removo do final:

public class Pilha<T> {
    private final ArrayList<T> elementos = new ArrayList<>();

    public void push(T t) {
        elementos.addLast(t);
    }

    public T pop() {
        return elementos.removeLast();
    }

    public boolean empty() {
        return elementos.isEmpty();
    }
}

Ok, agora vamos fazer a partir disso uma Fila<T>. Eu posso simplesmente quando chegar um novo elemento colocar na pilha? Posso, só preciso tomar cuidado na hora de remover o elemento: não posso remover com um simples pop, preciso garantir que seja o primeiro a entrar!

O jeito clássico de fazer isso é usando uma pilha secundária: ao chegar uma requisição de pop, eu recoloco os elementos da pilha principal na pilha secundária. O último elemento removido da pilha principal equivale à parte da frente da fila, portanto precisa ser retornado. Após isso, só colocar de volta no lugar os elementos que foram deslocados (em tese daria para otimizar para muitos pop seguidos, mas aqui o foco não é otimização):

public class Fila<T> {
    private final Pilha<T> elementos = new Pilha<>();
    private final Pilha<T> secundaria = new Pilha<>();

    public void push(T t) {
        elementos.push(t);
    }

    public T pop() {
        while (!elementos.empty()) {
            secundaria.push(elementos.pop());
        }
        final var v = secundaria.pop();
        while (!secundaria.empty()) {
            elementos.push(secundaria.pop());
        }
        return v;
    }

    public boolean empty() {
        return elementos.isEmpty();
    }
}

Existe uma outra maneira de imoplementar isso, que seria pegar o elemento antes do fim. Vai sacando os valores e, ao detectar o fim, retornar o elemento encontrado:

public class Fila<T> {
    private final Pilha<T> elementos = new Pilha<>();
    private final Pilha<T> secundaria = new Pilha<>();

    public void push(T t) {
        elementos.push(t);
    }

    public T pop() {
        while (true) {
            final var candidato = elementos.pop();
            if (elementos.empty()) {
                // devolve os elementos de volta
                while (!secundaria.empty()) {
                    elementos.push(secundaria.pop());
                }
                return candidato;
            }
            secundaria.push(candidato);
        }
    }

    public boolean empty() {
        return elementos.isEmpty();
    }
}

Uma pilha com duas filas

Bem, já que estamos trocando de empurrar no começo pro empurrar no fim, será que dá para pegar o exato mesmo algoritmo de duas pilhas simulando uma fila e fazer duas filas simulando uma pilha? Na real… dá sim!

Não importa o como vai ser implementada a fila em si, apenas que siga a convenção de comportamento. Então, podemos até assumir que vamos usar a fila desenvolvida na seção anterior.

Com isso fora de preoucupação, vamos seguir o mesmo formato de algoritmo:

public class Pilha<T> {
    private final Fila<T> elementos = new Fila<>();
    private final Fila<T> secundaria = new Fila<>();

    public void push(T t) {
        elementos.push(t);
    }

    public T pop() {
        while (true) {
            final var candidato = elementos.pop();
            if (elementos.empty()) {
                // devolve os elementos de volta
                while (!secundaria.empty()) {
                    elementos.push(secundaria.pop());
                }
                return candidato;
            }
            secundaria.push(candidato);
        }
    }

    public boolean empty() {
        return elementos.empty();
    }
}

Uma pilha com uma fila

Vamos pensar aqui qual o objetivo de se usar a fila secundária? Vamos fazer um desenho de como está sendo a questão do uso dessas coisas?

eu diminuo a fila principal
se eu cheguei no final da fila principal, o último elemento removido precisa ser retornado
se eu não cheguei no final da fila principal, preciso guardar o que foi removido
após detectar o momento do retorno, tudo que foi removido preciso ser inserido de volta na fila principal

Ou seja, eu preciso de:

indicador de fim
um buffer para restaurar a fila

E se… eu conseguir fazer isso usando apenas uma única fila? Bem, pra isso eu preciso trabalhar com a fila de modo… especial… No lugar da fila ter apenas elementos do tipo T, preciso que ela tenha um elemento tal que não seja do tipo T que eu possa diferenciar. As operações que eu faço via pilha são todas em cima de T, a API externa não muda. Mas internamente eu preciso de um novo elemento que seja incompatível com os elementos que estou inserindo. Algo semelhante foi usado para poder transformar função parcial em função total no artigo Criando mapas “apenas” com funções em java.

A minha primeira ideia seria fazer com que o backbone da implementação de Pilha<T> fosse Fila<Object> e eu iria inserir forçosamente um new Object(), que ficaria marcado no momento da criação como “elemento de diferenciação”. Mas então lembrei que eu posso fazer algo semelhante a um sum-type usando sealed interface (exploro mais isso no artigo Usando Java moderno para fazer aritmética de Peano):

sealed interface Elemento<V> {
    record Demarcador<V>() implements Elemento<V> {}
    record Container<V>(V v) implements Elemento<V> {}
}

Agora vou usar uma instância Demarcador para indicar que cheguei no final da fila. Se eu tenho um final forte, isso significa que eu posso simplesmente readicionar os elementos que eu tinha após o final da fila. Logo, isso significa que manter uma estrutura secundária apenas por buffer de elementos de torna desnecessário.

Agora, ao dar um pop, preciso verificar se o elemento é o demarcador. Se for, preciso retornar o elemento que foi sacado logo antes dele. Se não for um demarcador, preciso guardar o penúltimo elemento de volta na fila, e reservar o elemento que acabei de sacar para a próxima iteração:

public class Pilha<T> {

    private sealed interface Elemento<V> {
        record Demarcador<V>() implements Elemento<V> {}
        record Container<V>(V v) implements Elemento<V> {}
    }

    private final Fila<Elemento<T>> elementos = new Fila<>();
    
    public void push(T t) {
        elementos.push(new Elemento.Container<>(t));
    }
    
    public T pop() {
        elementos.push(new Elemento.Demarcador<>());
        Elemento.Container<T> penultimo = null;
        while (true) {
            final var candidato = elementos.pop();
            if (candidato instanceof Elemento.Container<T> anotherValue) {
                if (penultimo != null) {
                    elementos.push(penultimo);
                }
                penultimo = anotherValue;
            } else {
                return penultimo.v();
            }
        }
    }
    
    public boolean empty() {
        return elementos.empty();
    }
}

Como teste, adicionei 4 elementos e depois saquei até o esgotamento da pilha:

final var p = new Pilha<String>();
p.push("a");
p.push("b");
p.push("c");
p.push("d");
while (!p.empty()) {
    System.out.println(p.pop());
}

Note algumas coisas interessantes:

o elemento Demarcador só é inserido durante o processo de pop, e o processo de pop só termina após sacar o Demarcador
eu só preciso fazer a reinserção dos elementos após o segundo saque

Essa observação do “segundo saque” me leva a uma implementação alternativa, que incondicionalmente faz o primeiro saque e reserva o valor, antes mesmo de sequer cogitar inserir o demarcador. A ideia é:

saca o elemento
se estiver vazio, retorna o elemento
se não estiver vazio, reserva esse elemento
insere o demarcador
continue sacando próximos elementos
se o elemento sacado for demarcador, retorne o elemento reservado
se não, insira o elemento reservado de volta e reserve o elemento sacado

public T pop() {
    var reservado = (Elemento.Container<T>) elementos.pop();
    if (elementos.empty()) {
        return reservado.v();
    }
    elementos.push(new Elemento.Demarcador<>());
    while (true) {
        final var candidato = elementos.pop();
        if (candidato instanceof Elemento.Container<T> anotherValue) {
            elementos.push(reservado);
            reservado = anotherValue;
        } else {
            return reservado.v();
        }
    }
}

Reinventando a roda: como escrever streams sem usar stream como base

Wed, 06 May 2026 00:00:00 +0000

Era uma vez um mundo de Java 7. Não existiam streams no Java, não existiam lambdas no Java (classes anônimas seriam uma aproximação, mas não conta porque elas são bem anti-práticas).

E desse mundo eu conheci as maravilhas da programação funcional em Java, e um problema comum de mutabilidade de estados poderia ser resolvido usando streams.

O primeiro problema era como representar uma função de modo prático, e graças ao Retrolambda foi possível adicionar lambdas no projeto. Próximo passo? Fazer as streams.

Dada as limitações que eu tinha da época, eu precisava ter uma API próxima o suficiente de streams, não precisa literalmente algo 100% sem atrito de fazer um someList.stream(). Uma alterativa seria usar um new Stream<>(someList) ou então Stream.streamify(someList).

Com isso, eu poderia ter o poder das streams na minha mão. E, acredite, para a época ter toda uma biblioteca para emular algo semelhante a streams valeu o esforço.

Quem estiver curioso, muito do artefato produzido ficou na biblioteca open-source chamada de functional-toolbox.

Setando limitações iniciais

Bem, a primeira limitação é que precisa ser algo feito em cima de um iterável. A stream produzida precisa receber um iterável e retornar algo com uma API stream-like.

Em java, a interface Iterable<T> tem um único método aberto chamado de iterator() que produz um Iterator<T>.

Apesar de na especificação Java Stream<T> ser uma interface, não há essa necessidade no caso do clone de streams que faremos aqui.

Não iremos reaproveitar objetos. Uma vez que se faz, por exemplo, transformIntoStream(someList).map(someFunction), iremos primeiro criar um objeto com a API stream-like na chamada transformIntoStream e, em seguida, criar um novo objeto ao chamar map.

Spliterators não são permitidos nessa primeira reinvenção de roda, visto que não seria possível acessá-los na época de um runtime compatível com Java 7 sem precisar reinventá-los. Como não era necessário um spliterator para o que se estava trabalhando, mas sim a API de algo semelhante a stream (e, também, da coleção de Collectors disponível por padrão), spliterator não vai ser levado em consideração.

Intefaces funcionais não precisam ser estritamente compatíveis por nome 1:1 com o que se tem no Java, mas precisa ter o mesmo método aberto. Por exemplo, um map na stream do Java recebe uma java.util.function.Function<T, R> que tem um método aberto R apply(T). Isso significa que eu posso ter uma interface do tipo myjava.Function<T, R> com um único método, aberto ainda por cima, R apply(T). Por simplicidade (e porque de fato o runtime permitia) não iremos recriar as interfaces, iremos usá-las, mas estando limitado apenas ao método aberto. Se for desejável usar algo como <V> Function<V,R> compose(Function<V,T>) então não poderia simplesmente fazer func.compose(otherFunc), mas sim FunctionUtils.compose(func, otherFunc).

Outra limitação é, por mais que seja difícil, é abrir mão de novidades do Java. Eu preciso usar como target Java 8, para poder rodar o Retrolambda e transformar o bytecode para Java 7. Então, de modo geral, a API que eu vou usar precisa ser compatível com o Java 7. Porém, devido a questões da facilidade da plataforma alvo, eu posso usar as interfaces funcionais.

As limitações de sintaxe tem um pouco mais de liberdade, mas mesmo assim vou tentar de manter nas restrições que eu tinha na época: posso usar tudo do Java 7 e também lambdas. Entretanto, não posso usar anotações em runtime, só para geração de código.

Para códigos de teste, vou me dar a possibilidade de chamar List.of, isso facilita demais o trabalho sem perder a generalidade.

Em resumo, minhas limitações são:

Java 7 (menos anotações de runtime)
sem métodos default de interface
sem métodos estáticos de interface
interfaces funcionais do Java 8 (Supplier, Consumer, Function etc)
lambdas liberado

Para testes não preciso de nenhuma restrição (afinal, a restrição só pra produção), mas vou tentar manter o máximo possível de compatibilidade com as restrições acima.

Fora de escopo

Fazer a stream ser auto-closeable não está no escopo atual. Vamos fazer essa adaptação em outra publicação?

Além disso, stream e optional focados em primitivos vão ser deixados de lado nesse momento, visto que a intenção maior é fornecer a DX adequada para o fluxo de trabalho. Então, fica aqui a promessa de fazer uma outra implementação com isso também.

Também não vou dar muito foco nas variantes unmodifiable nem concurrent.

Estratégia de desenvolvimento

Dadas essas limitações, o primeiro alvo deve ser alcançar o forEach. O primeiro desenvolvimento deve ser alcançar essa operação terminal. Hello world? Vamos imprimir uma lista de strings.

Depois dessa operação terminal, podemos passar para uma operação intermediária. Nada como map aqui para transformar o tipo. Podemos pegar a lista de palavras e transformar em uma lista de comprimentos de palavras. Aqui uma operação de transformação de tipos do jeito errado geraria um ClassCastException, o que é uma ótima maneira de detectar a falha ao rodar.

A operação de map mantém a mesma quantidade de elementos. Outro passo intermediário porém mais problemático (e, portanto, melhor para se aprender) é o filter, justamente porque ele altera a quantidade de elementos.

Em seguida, coletar (primeiro com reduce, em seguida com collect mesmo). Os coletores mais simples são toList e toSet, que podem ser tratados como simplesmente casos especiais de toCollection.

Primeiras implementações: stream

A base é um Iterable<T>, que na prática é um jeito de gerar Iterator<T>. O Iterator<T> por sua vez é uma estrutura mutável que tem apenas dois métodos:

hasNext permite saber se é possível chamar next e o resultado ser confiável
next retorna o elemento atual do iterador e avança o ponteiro

Vamos usar uma classe para se comportar como stream. Como ela vai receber um Iterable<T>, temos isso:

public class Stream<T> {
    private final Iterable<T> it;

    public Stream(Iterable<T> it) {
        this.it = it;
    }
}

Pronto, agora vamos separar regiões para operações intermediárias e operações terminadoras:

public class Stream<T> {
    private final Iterable<T> it;

    public Stream(Iterable<T> it) {
        this.it = it;
    }

    // intermediate operations

    // terminal operations
}

E, por fim, as factories! Como .of(1, 2, 3) e .iterate(seed, operator)!

public class Stream<T> {
    private final Iterable<T> it;

    public Stream(Iterable<T> it) {
        this.it = it;
    }

    // intermediate operations

    // terminal operations

    // factories
}

forEach

O forEach é uma operação tranquila: só preciso consumir o que é gerado pelo iterável:

public void forEach(Consumer<T> action) {
    for (T t: it) {
        action.accept(t);
    }
}

Se não quisermos usar a estrutura do for-each do Java, podemos transformar o Iterable<T> em um Iterator<T> e consumir num laço for:

public void forEach__classicFor(Consumer<T> action) {
    for (Iterator<T> iterator = it.iterator(); iterator.hasNext();) {
        final T t = iterator.next();
        action.accept(t);
    }
}

Alternativa com while:

public void forEach__while(Consumer<T> action) {
    final Iterator<T> iterator = it.iterator();
    while (iterator.hasNext()) {
        final T t = iterator.next();
        action.accept(t);
    }
}

Aqui foram apresentadas essas alternativas por pura curiosidade, o padrão vai ser usar for-each se possível (na maioria dos casos não é).

map

Vamos mapear. Agora, vamos precisar gerar uma nova stream, não podemos modificar o objeto. E também vamos deixar ela ser lazy! Nada de coletar em uma lista (ocupar a memória) e depois passar a usar essa lista. Vamos encadear várias e várias vezes, não tem porque juntar.

Então, bora lá! O map vai receber uma função T -> R. E o retorno vai ser uma Stream<R>. E como construímos Stream<R>? Com um Iterable<R>.

Agora, o Iterable<T> é uma classe que possui um único método, que retorna um Iterator<T>. Posso representar por um lambda! (Já que tenho Retrolambda!)

Mas o Iterator<T> é uma classe que tem estado, precisa manter noção de que tem um next, o hasNext, essas coisas. O esqueleto da função seria isso:

public <R> Stream<R> map(Function<T, R> mapper) {
    return new Stream<>(() -> new Iterator<>() {
        
        @Override
        public boolean hasNext() {
            return false;
        }

        @Override
        public R next() {
            return null;
        }
    });
}

Agora, como preencher isso? Para começar, que tal manter o iterador da stream com o elemento a ser sacado como estado desse Iterador? Algo assim:

public <R> Stream<R> map(Function<T, R> mapper) {
    return new Stream<>(() -> new Iterator<>() {

        private final Iterator<T> innerIterator;
        
        {
            this.innerIterator = it.iterator();
        }

        @Override
        public boolean hasNext() {
            return false;
        }

        @Override
        public R next() {
            return null;
        }
    });
}

E agora? Bem, podemos fazer um wrapper puro. Se o innerIterator tiver elementos, eu garanto que o meu next irá existir:

@Override
public boolean hasNext() {
    return innerIterator.hasNext();
}

E quanto ao next? Bem, agora usamos a função para mapear o que o iterador interno nos responder˜

@Override
public R next() {
    final T el = innerIterator.next();
    return mapper.apply(el);
}

Vamos testar?

final Stream<Integer> s = new Stream<>(List.of(1, 2, 3));
s.map(x -> 2*x).forEach(System.out::println);

E isso imprime corretamente:

2
4
6

Tá, mas isso não alterou o tipo, né? E que tal… se eu transformar em string, então pegar o comprimento desse número como inteiro, e imprimir?

final Stream<Integer> s = new Stream<>(List.of(1, 2, 3));
s.map(i -> stringify(i)).map(String::length).forEach(System.out::println);

static String stringify(int i) {
    switch (i) {
        case 0: return "zero";
        case 1: return "um";
        case 2: return "dois";
        case 3: return "tres";
        case 4: return "quatro";
        case 5: return "cinco";
        case 6: return "seis";
        case 7: return "sete";
        case 8: return "oito";
        case 9: return "nove";
        default: return "muito grande";
    };
}

Ele imprime:

2
4
4

Que é o comprimento de um, dois e seis, respectivamente. Então, feliz, conseguimos! Fizemos o mapeamento!

filter

O filter não muda o tipo. Ou seja, eu só posso usar o que eu resgatei, não altero o objeto resgatado. Porém, nesse caso, eu vou selecionar qual o objeto que eu de fato vou retornar.

Como para saber se tenho um próximo elemento na prática eu preciso alterar o valor do iterador, vou já fazer um “pre-fetch” para saber qual o próximo elemento (se é que existe). Assim, eu vou sempre saber se tenho um próximo e qual seria esse próximo. O iterador vai ser lazy, apenas um pequeno fetch inicial mais eager do que absolutamente lazy, o que tá dentro das limitações.

Então, bora lá? Vamos criar uma rotina para buscar o próximo elemento válido segundo o filtro, que vai povoar ao mesmo tempo uma variável para indicar se tem próximo e também qual o próximo em questão. Eventualmente o próximo pode ser nulo, por sinal.

Se essa rotina existir, como que a gente poderia usar ela? Bem, na construção do objeto, eu a chamo e povoo as variáveis _next e _hasNext. Já, ao chamar o hasNext() do iterador, eu simplesmente retorno _hasNext. Ao chamar o next() do iterador, eu preciso retornar o elemento que tenho em mãos e chamar essa função:

public Stream<T> filter(Predicate<T> filter) {
    return new Stream<>(() -> new Iterator<>() {

        private final Iterator<T> innerIterator;
        private boolean _hasNext;
        private T _next;
        
        {
            this.innerIterator = it.iterator();
            magicFunction();
        }

        @Override
        public boolean hasNext() {
            return _hasNext;
        }

        @Override
        public T next() {
            final T returnedValue = _next;
            magicFunction();
            return returnedValue;
        }

        private void magicFunction() {
            // ...
        }
    });
}

Ok, parece ser bom o suficiente. Então, para o algoritmo! Eu só posso continuar iterando enquanto eu tenho um próximo elemento. Se eu achar um elemento que passe no filtro, eu salvo o elemento e paro a iteração. Se eu chegar no final da iteração, preciso apenas marcar que não tem próximo e finalizar.

private void magicFunction() {
    while (innerIterator.hasNext()) {
        final T element = innerIterator.next();
        if (filter.test(element)) {
            // o primeiro que encontra que satisfaz a condição para o laço
            _next = element;
            _hasNext = true;
            return;
        }
    }
    _next = null; // apenas para marcar que não tem
    _hasNext = false;
}

Vamos testar? Vamos pegar uma lista e filtrar apenas os pares:

final Stream<Integer> s = new Stream<>(List.of(1, 2, 3, 4, 5, 6));
s.filter(i -> i%2 == 0).forEach(System.out::println);

Como esperado:

2
4
6

peek

Nada de segredo aqui: o peek permite interceptar um elemento no meio do pipeline de streaming sem alterar o elemento em si. Portanto, pode ser usado para simplesmente gerar um efeito colateral.

Vai ser bem parecido com o map, porém aqui não há intenção de mapear o valor, apenas de realizar um efeito colateral com ele:

public Stream<T> peek(Consumer<T> action) {
    return new Stream<>(() -> new Iterator<>() {

        private final Iterator<T> innerIterator;
        
        {
            this.innerIterator = it.iterator();
        }

        @Override
        public boolean hasNext() {
            return innerIterator.hasNext();
        }

        @Override
        public T next() {
            final T el = innerIterator.next();
            action.accept(el);
            return el;
        }
    });
}

Usando aqui para verificar se de fato a stream está passando por todos os elementos antes do filtro ser aplicado, acumulando em uma lista, apenas como um exemplo bem artificial do que se pode fazer com o peek:

final Stream<Integer> s = new Stream<>(List.of(1, 2, 3, 4, 5, 6));
final ArrayList<Integer> l = new ArrayList<>();
s.peek(i -> System.out.println(stringify(i))).filter(i -> i%2 == 0).forEach(l::add);
System.out.println(l);

Saída:

um
dois
tres
quatro
cinco
seis
[2, 4, 6]

Se for por em contraste a estratégia do filter colocando o peek, pode-se observar que a estragégia do pipeline do Java padrão é diferente da estratégia que usei aqui. Aqui eu procuro sempre responder o hasNext e ter isso carregado, já no stream padrão do Java ele de fato é completamente lazy. Isso foi uma escolha de design razoável para o local de aplicação.

limit

Agora precisamos permitir que apenas uma pequena quantidade de elementos seja passada. Aqui, se por acaso a quantidade de elementos resgatados ultrapassar um valor, preciso barrar e falar “já deu”, mesmo que eventualmente tenha mais coisas para se tratar.

Basicamente, cada next vai remover um do “pool” que posso remover. Se chegar no final do iterável antes desse “pool”, chegou, fim. Caso contrário, o “pool” indica que a coisa já deu, e que não tem mais nada:

public Stream<T> limit(long maxSize) {
    return new Stream<>(() -> new Iterator<>() {

        private final Iterator<T> innerIterator;
        private long remaining = maxSize;
        
        {
            this.innerIterator = it.iterator();
        }

        @Override
        public boolean hasNext() {
            return remaining > 0 && innerIterator.hasNext();
        }

        @Override
        public T next() {
            if (remaining <= 0) {
                throw new NoSuchElementException("End of stream: read more than " + maxSize + " elements");
            }
            remaining--;
            return innerIterator.next();
        }
    });
}

Vamos testar? limit(3) na lista de 6 inteiros:

final Stream<Integer> s = new Stream<>(List.of(1, 2, 3, 4, 5, 6));
s.limit(3).forEach(System.out::println);

E funcionou perfeitamente!

1
2
3

Testado para limit(15) também, sem surpresa alguma: deixou passar todos os elementos.

skip

Bem, ao contrário do limit que, digamos, deixava o iterador rodar até o final, aqui bem dizer precisamos ser eager e já pular esses elementos. Aqui podemos deixar pra fazer isso em um processo de inicialização a ser chamado seja no hasNext ou no next, não precisa ser no construtor (apesar de que também é viável assim):

public Stream<T> skip(long n) {
    return new Stream<>(() -> new Iterator<>() {

        private final Iterator<T> innerIterator;
        private boolean initialized = false;
        
        {
            this.innerIterator = it.iterator();
        }

        @Override
        public boolean hasNext() {
            init();
            return innerIterator.hasNext();
        }

        @Override
        public T next() {
            init();
            return innerIterator.next();
        }

        private void init() {
            if (initialized) {
                return;
            }
            initialized = true;
            for (long i = 0; i < n; i++) {
                if (!innerIterator.hasNext()) {
                    return;
                }
                innerIterator.next();
            }
        }
    });
}

O mesmo teste feito para limit, skip(3):

final Stream<Integer> s = new Stream<>(List.of(1, 2, 3, 4, 5, 6));
s.skip(3).forEach(System.out::println);

Impresso conforme esperado:

4
5
6

Funcionou perfeitamente bem para números além da quantidade de elementos também.

flatMap

O flatMap é um dos mais delícias de fazer! Porque agora um elemento pode se transformar em múltiplos!

Então, como resolver? Bem, eu posso chegar lá, pegar a stream retornada e, como é um objeto do meu tipo, acessar o campo privado dela e resgatar um Iterator adequado e iterar em cima dele! Bonito? Não, mas dá conta do recado!

Primeiro passo: garantir que eu tenho um interator do outro tipo disponível. Isso é literalmente o primeiro passo e não deve se repetir nunca!

public <R> Stream<R> flatMap(Function<T, Stream<R>> mapper) {
    return new Stream<>(() -> new Iterator<>() {

        private final Iterator<T> innerIterator;
        private Iterator<R> otherTypeIterator = null;

        {
            this.innerIterator = it.iterator();
        }
        
        @Override
        public boolean hasNext() {
            fetchNext();
            return false; // placeholder
        }

        @Override
        public R next() {
            fetchNext();
            return null; // placeholder
        }
        
        private void fetchNext() {
            if (otherTypeIterator == null) {
                // primeira vez
                if (innerIterator.hasNext()) {
                    final T el = innerIterator.next();
                    final Stream<R> intermediateStream = mapper.apply(el);
                    otherTypeIterator = intermediateStream.it.iterator();
                }
            }
            // continuar processo
        }
    });
}

Próximo passo? Agora que eu tenho garantidamente o iterador do outro tipo, o que fazer com ele?

Hmmm, mas e o caso do else se não tiver elementos no innerIterator? Bem, aqui é de certo modo “fácil”: crio um iterador vazio e deixo seguir como se fosse o caso anterior:

private void fetchNext() {
    if (otherTypeIterator == null) {
        // primeira vez
        if (innerIterator.hasNext()) {
            final T el = innerIterator.next();
            final Stream<R> intermediateStream = mapper.apply(el);
            otherTypeIterator = intermediateStream.it.iterator();
        } else {
            otherTypeIterator = new Iterator<>() {
                @Override
                public boolean hasNext() {
                    return false;
                }

                @Override
                public R next() {
                    throw new NoSuchElementException("No element");
                }
            };
        }
    }
    // continuar processo
}

Ok, agora eu tenho certeza do otherTypeIterator. Bem, se ele tiver um elemento, eu pego esse elemento. Aqui vou usar uma estratégia similar a o que usei no filter, com o _hasNext e com o _next:

private void fetchNext() {
    if (otherTypeIterator == null) {
        // primeira vez
        if (innerIterator.hasNext()) {
            final T el = innerIterator.next();
            final Stream<R> intermediateStream = mapper.apply(el);
            otherTypeIterator = intermediateStream.it.iterator();
        } else {
            otherTypeIterator = new Iterator<>() {
                @Override
                public boolean hasNext() {
                    return false;
                }

                @Override
                public R next() {
                    throw new NoSuchElementException("No element");
                }
            };
        }
    }
    // continuar processo
    if (otherTypeIterator.hasNext()) {
        _hasNext = true;
        _next = otherTypeIterator.next();
        return;
    }
}

Parece bom? Bem, é um passo. Mas talvez ele não tenha mais elementos, portanto preciso iterar no innerIterator. Basicamente essa iteração vai ser até esgotar tudo, um laço infinito: dou um fetch do próximo iterador e, se ele for vazio, sigo no laço; caso de não ter mais nada nem no otherTypeIterator nem no innerIterator, paro ali indicando que não tem mais nada:

private void fetchNext() {
    if (otherTypeIterator == null) {
        // primeira vez
        if (innerIterator.hasNext()) {
            final T el = innerIterator.next();
            final Stream<R> intermediateStream = mapper.apply(el);
            otherTypeIterator = intermediateStream.it.iterator();
        } else {
            otherTypeIterator = new Iterator<>() {
                @Override
                public boolean hasNext() {
                    return false;
                }

                @Override
                public R next() {
                    throw new NoSuchElementException("No element");
                }
            };
        }
    }
    // continuar processo
    while (true) {
        if (otherTypeIterator.hasNext()) {
            _hasNext = true;
            _next = otherTypeIterator.next();
            return;
        } else if (innerIterator.hasNext()) {
            final T el = innerIterator.next();
            final Stream<R> intermediateStream = mapper.apply(el);
            otherTypeIterator = intermediateStream.it.iterator();
        } else {
            _next = null; // apenas para marcar que não tem
            _hasNext = false;
            return;
        }
    }
}

Hmmm, podemos melhorar essa conversa de extrair o otherTypeIterator!

private void fetchNext() {
    if (otherTypeIterator == null) {
        // primeira vez
        if (innerIterator.hasNext()) {
            otherTypeIterator = getOtherTypeIterator(innerIterator.next());
        } else {
            otherTypeIterator = new Iterator<>() {
                @Override
                public boolean hasNext() {
                    return false;
                }

                @Override
                public R next() {
                    throw new NoSuchElementException("No element");
                }
            };
        }
    }
    while (true) {
        if (otherTypeIterator.hasNext()) {
            _hasNext = true;
            _next = otherTypeIterator.next();
            return;
        } else if (innerIterator.hasNext()) {
            otherTypeIterator = getOtherTypeIterator(innerIterator.next());
        } else {
            _next = null; // apenas para marcar que não tem
            _hasNext = false;
            return;
        }
    }
}

private Iterator<R> getOtherTypeIterator(T el) {
    final Stream<R> intermediateStream = mapper.apply(el);
    return intermediateStream.it.iterator();
}

Ok! Agora, bem… o hasNext deve ser seguro de se chamar múltiplas vezes. Em tese eu posso fazer it.hasNext(); it.hasNext(); como se fosse igual a it.hasNext() sem maiores consequências. Portanto, eu não posso chamar fetchNext toda vida ao bater no hasNext! Preciso só chamar caso não tenha sido ainda inicializado! Vamos refazer ele:

@Override
public boolean hasNext() {
    if (otherTypeIterator == null) {
        fetchNext();
    }
    return _hasNext;
}

Ok, parece justo agora. E quanto ao next? Bem, lembra do filter? Ele faz algo bem semelhante, podemos beber da ideia! E também garantir a inicialização que nem no hasNext!

@Override
public R next() {
    if (otherTypeIterator == null) {
        fetchNext();
    }
    final R r = _next;
    fetchNext();
    return r;
}

Vamos testar? Dado um número, o mapeamento vai ser todos os inteiros menores do que ele em ordem crescente:

static Stream<Integer> positivosMenoresCrescente(int n) {
    ArrayList<Integer> acc = new ArrayList<>();
    for (int i = 1; i < n; i++) {
        acc.add(i);
    }
    return new Stream<>(acc);
}

E o teste?

final Stream<Integer> s = new Stream<>(List.of(1, 2, 3, 4, 5, 6));
s.flatMap(i -> positivosMenoresCrescente(i)).forEach(System.out::println);

Com o resultado esperado:

distinct

Podemos fazer isso aqui como uma abstração acima do filter. Se o elemento for novo em um HashSet do tipo apropriado, deixa passar!

public Stream<T> distinct() {
    HashSet<T> x = new HashSet<>();
    return filter(x::add);
}

Para o teste? Bem, vamos usar o flatMap anterior, junto com o distinct:

final Stream<Integer> s = new Stream<>(List.of(1, 2, 3, 4, 5, 6));
s.flatMap(i -> positivosMenoresCrescente(i))
    .distinct()
    .forEach(System.out::println);

Resultado conforme esperado:

Streams do java utilizam flags para indicar se estão ordenadas, entre outras coisas, que permitiriam muita otimização. Aqui, por simplicidade, não farei isso. Vai ser do modo comum, sem otimização alguma.

sorted

Aqui… bem, aqui vou precisar consumir completamente a stream que veio, e então aplicar a ordenação. Existem dois sabores de sorted: o que recebe o comparador, e o que assume ser ordenação natural. Vamos primeiro lidar com o sorted que recebe o comparador.

Primeiro, vamos juntar todos os elementos:

public Stream<T> sorted(Comparator<T> comparator) {
    ArrayList<T> list = new ArrayList<>();
    for (T el: it) {
        list.add(el);
    }
    return this; // placeholder
}

Ok, e agora? Agora, vamos ordenar a lista acumulada e retornar o stream sobre ela:

public Stream<T> sorted(Comparator<T> comparator) {
    ArrayList<T> list = new ArrayList<>();
    for (T el: it) {
        list.add(el);
    }
    list.sort(comparator);
    return new Stream<>(list);
}

E quanto ao sorted que usa ordem natural? Bem, esse eu vou… fazer uma gambiarra mesmo 🤷‍♂️ Vou fazer um cast e pronto:

public Stream<T> sorted() {
    return sorted((Comparator<T>) Comparator.naturalOrder());
}

Vamos testar?

final Stream<Integer> s = new Stream<>(List.of(1, 2, 3, 4, 5, 6));
s.map(i -> stringify(i))
    .sorted()
    .forEach(System.out::println);

Isso já testa ao mesmo tempo se o sorted por ordenação natural funciona e se também se o sorted passando um comparador explícito funciona. E o resultado?

cinco
dois
quatro
seis
tres
um

Perfeito! Agora, vamos ver se ele aceita algo que não seja um Comparable? Vamos criar um Wrapper bem tosquinho?

static class Wrapper {
    final String s; 
    Wrapper(String s) {
        this.s = s;
    }

    @Override
    public String toString() {
        return "[wrapping <" + s + ">]";
    }
}

E o código em si:

final Stream<Integer> s = new Stream<>(List.of(1, 2, 3, 4, 5, 6));
s.map(i -> stringify(i))
    .map(Wrapper::new)
    .sorted()
    .forEach(System.out::println);

Com resultado:

Exception in thread "main" java.lang.ClassCastException: class com.jeffque.Main$Wrapper cannot be cast to class java.lang.Comparable

Agora, para corrigir isso? Transformar o Wrapper em um Comparable<Wrapper>:

static class Wrapper implements Comparable<Wrapper> {
    final String s; 
    Wrapper(String s) {
        this.s = s;
    }

    @Override
    public String toString() {
        return "[wrapping <" + s + ">]";
    }

    @Override
    public int compareTo(Wrapper o) {
        return this.s.compareTo(o.s);
    }
}

Sem mudanças em como o stream é testado:

[wrapping <cinco>]
[wrapping <dois>]
[wrapping <quatro>]
[wrapping <seis>]
[wrapping <tres>]
[wrapping <um>]

E se eu não quiser agora passar um Comparator explícito?

static class Wrapper {
    final String s; 
    Wrapper(String s) {
        this.s = s;
    }

    @Override
    public String toString() {
        return "[wrapping <" + s + ">]";
    }

    public int aaaa(Wrapper o) {
        return this.s.compareTo(o.s);
    }
}

final Stream<Integer> s = new Stream<>(List.of(1, 2, 3, 4, 5, 6));
s.map(i -> stringify(i))
    .map(Wrapper::new)
    .sorted(Wrapper::aaaa)
    .forEach(System.out::println);

count

Para essa operação final, vamos só esgotar a quantidade de elementos do iterador, estilo o que fizemos no sorted:

public long count() {
    long acc = 0;
    for (T el: it) {
        acc++;
    }
    return acc;
}

Experimentos? Vamos imprimir o total e para o caso com filtro de apenas números pares:

final Stream<Integer> s = new Stream<>(List.of(1, 2, 3, 4, 5, 6));
System.out.println(s.count());

// ...

final Stream<Integer> s = new Stream<>(List.of(1, 2, 3, 4, 5, 6));
System.out.println(s.filter(i -> i % 2 == 0).count());

E a impressão deu conforme o esperado:

6
3

min e max

Aqui temos praticamente a mesma implementação. Vamos primeiramente verificar se está vazio. Estando vazio, retornamos Optional.empty() (ah, sim, teremos uma seção dedicada a sua implementação).

Então, caso contrário, peguemos o primeiro elemento, e depois esgotamos a stream, sempre comparando com o menor obtido até então:

public Optional<T> min(Comparator<T> comparator) {
    final Iterator<T> iterator = it.iterator();
    if (!iterator.hasNext()) {
        return Optional.empty();
    }
    T minimumElement = iterator.next();
    while (iterator.hasNext()) {
        final T el = iterator.next();
        // se o menor elemento _até agora_ for maior que o elemento sendo
        // inspecionado, atuliza o menor elemento encontrado
        if (comparator.compare(minimumElement, el) > 0) {
            minimumElement = el;
        }
    }
    return Optional.of(minimumElement);
}

De modo semelhante, temos o max:

public Optional<T> max(Comparator<T> comparator) {
    final Iterator<T> iterator = it.iterator();
    if (!iterator.hasNext()) {
        return Optional.empty();
    }
    T maximumElement = iterator.next();
    while (iterator.hasNext()) {
        final T el = iterator.next();
        // se o maior elemento _até agora_ for menor que o elemento sendo
        // inspecionado, atuliza o maior elemento encontrado
        if (comparator.compare(maximumElement, el) < 0) {
            maximumElement = el;
        }
    }
    return Optional.of(maximumElement);
}

Para testar? Usemos o Integer::compareTo:

final Stream<Integer> s = new Stream<>(List.of(1, 2, 3, 4, 5, 6));
System.out.println(s.min(Integer::compareTo));
// Optional[1]

max?

final Stream<Integer> s = new Stream<>(List.of(1, 2, 3, 4, 5, 6));
System.out.println(s.max(Integer::compareTo));
// Optional[6]

Se quiser também podemos pegar a subtração dos números como Comparator:

final Stream<Integer> s = new Stream<>(List.of(1, 2, 3, 4, 5, 6));
System.out.println(s.min((a, b) -> a - b));
// Optional[1]

findFirst e findAny

O findFirst, bem dizer, é só ver se tem algo, retornando esse algo:

public Optional<T> findFirst() {
    final Iterator<T> iterator = it.iterator();
    if (!iterator.hasNext()) {
        return Optional.empty();
    }
    return Optional.of(iterator.next());
}

O comportamento padrão do Java é não permitir nulos no findFirst, por isso mantive o Optional.of.

A ideia do findAny no Java era uma otimização para retornar qualquer elemento que potencialmente pudesse existir na stream. Por exemplo, em um TreeMap, o findAny não iria precisar rodar até encontrar o elemento relativo da menor chave registrada, poderia simplesmente retornar o elemento associado à raiz.

Como aqui sempre vamos de um iterator, não precisamos necessariamente otimizar. Então vou fazer o findAny simplesmente apontar pro findFirst:

public Optional<T> findAny() {
    return findFirst();
}

A ideia dessas streams é permitir uma melhor experiência programando, não suprir com grande performance. Então essas coisas são aceitáveis, até porque as streams daqui não são para ARTS (almost real time systems).

anyMatch, allMatch, noneMatch

Todas aqui são estruturas que tem curto circuito com um teste. No caso do anyMatch, o primeiro retorno positivo retorna true. No caso do noneMatch, o primeiro retorno positivo retorna false. O allMatch retorna falso no primeiro negativo que encontrar.

Esse tipo de operação permite fazer um for-each:

public boolean anyMatch(Predicate<T> t) {
    for (final T el: it) {
        if (t.test(el)) {
            return true;
        }
    }
    return false;
}

O noneMatch?

public boolean noneMatch(Predicate<T> t) {
    for (final T el: it) {
        if (t.test(el)) {
            return false;
        }
    }
    return true;
}

E finalmente, o allMatch:

public boolean allMatch(Predicate<T> t) {
    for (final T el: it) {
        if (!t.test(el)) {
            return false;
        }
    }
    return true;
}

Para comparar, usemos pequenas variações de predicados:

i -> i > 5: deve dar verdade para anyMatch apenas
i -> i > 7: deve dar verdade para noneMatch apenas
i -> i > 0: deve dar verdade para allMatch e anyMatch

toArray

Aqui temos duas variantes: uma que vai retornar um Object[], e outra que vai gerar um A[] baseado em um int. Para construir o array, de toda sorte, vou precisar juntar a stream inteira. O tipo A não precisa necessariamente estar relacionado com o tipo T.

Bem, o ArrayList tem um método chamado toArray passando um array. Se não tiver o tamanho adequado, ele gera um novo array com o tamanho certo; caso você passe um array com o tamanho adequado (maior ou igual à quantidade de itens), ele povoa o array com os elementos.

Então, bem, vamos usar primeiro o int -> A[], e então depois o que gera o Object[].

Para testar, vamos usar o exemplo do flatMap, porém para deixar mais fácil examinar o resultado usemos também o sorted:

final Stream<Integer> s = new Stream<>(List.of(1, 2, 3, 4, 5, 6));
final Integer[] a = s.flatMap(i -> positivosMenoresCrescente(i)).sorted().toArray(Integer[]::new);
System.out.println(a.getClass());
for (final int i: a) {
    System.out.println(i);
}

Como a ideia é acumular em um ArrayList e depois passar para o array recém criado com o tamanho certo, vamos iterar e acumular:

public <A> A[] toArray(IntFunction<A[]> arrayBuilder) {
    ArrayList<T> arr = new ArrayList<>();
    for (final T el: it) {
        arr.add(el);
    }
    return arr.toArray(arrayBuilder.apply(arr.size()));
}

A saída:

class [Ljava.lang.Integer;
1
1
1
1
1
2
2
2
2
3
3
3
4
4
5

Conforme esperado.

Agora, para o toArray sem especificar a função que cria o array? Bem, vamos aqui simplesmente passar um Object[]::new para retornar o array, e assim deixamos a carga pesada toda em um único ponto:

public Object[] toArray() {
    return toArray(Object[]::new);
}

forEachOrdered

Aqui é só para garantir o processamento dos itens de acordo com o que eles são produzidos na stream. Isso é útil quando temos processamento em paralelo ou fora da ordem. Mas para o nosso caso já processamos na ordem de geração.

Aqui, o forEachOrdered é apenas um wrapper para o forEach:

public void forEachOrdered(Consumer<T> action) {
    forEach(action);
}

reduce

O reduce aqui vem em 3 sabores:

o que não se conhece a identidade (retorna um Optional<T>)
o que se conhece o elemento neutro e se acumula nele (retorna um T)
o que se conhece o elemento neutro, e se combina ele com o próximo elemento de modo arbitrário, e eventualmente se unem os elementos combinados (retorna um U)

Aqui vou tratar o primeiro sabor como algo a parte, e o segundo sabor como um sabor especial do terceiro: se o elemento neutro é do tipo do resultado de sua combinação com o tipo novo, então podemos usar essa mesma função para combinar esses elementos acumulados também.

Para teste, vamos usar dois tipos de acumulações distintas: a primeira vai ser mantendo o mesmo tipo (no caso, vamos pra multiplicação), e pro segundo caso vamos para uma mudança de tipo brusca: vamos juntar em uma lista minha, uma variação do que foi usado em Usando Java moderno para fazer aritmética de Peano, porém com os limites de não poder usar record nem sealed interface.

Para os dois primeiros sabores, vai ser em cima do mesmo tipo, então vai ser só o exemplo da soma. No terceiro sabor, vamos usar tanto a soma quanto o acúmulo na lista.

Como o exemplo mais fácil é a soma, não vamos encrencar com outra coisa antes, vamos fazer o reduce de um elemento logo:

final Stream<Integer> s = new Stream<>(List.of(1, 2, 3, 4, 5, 6));
final Optional<Integer> sum = s.reduce((a, b) -> a + b);
System.out.println(sum);
// Optional[21]

Vou seguir aqui o mesmo esquema usado no min:

public Optional<T> reduce(BinaryOperator<T> acc) {
    final Iterator<T> iterator = it.iterator();
    if (!iterator.hasNext()) {
        return Optional.empty();
    }
    T r = iterator.next();
    while (iterator.hasNext()) {
        final T el = iterator.next();
        r = acc.apply(r, el);
    }
    return Optional.of(r);
}

Ok, e agora para o outro sabor da soma, passando o elemento neutro? O reduce vai passar para o reduce com o combinador o mesmo elemento passado como acumulador:

public T reduce(T identity, BinaryOperator<T> acc) {
    return reduce(identity, acc, acc);
}

E para o terceiro sabor? Bem, primeiro temos a identidade. Tendo a identidade, cada elemento novo recebido podemos acumular na identidade e ser feliz:

public <U> U reduce(U identity, BiFunction<U, T, U> acc, BinaryOperator<U> comb) {
    U r = identity;
    for (final T el: it) {
        r = acc.apply(r, el);
    }
    return r;
}

O teste é bem similar, só precisa por o elemento neutro:

final Stream<Integer> s = new Stream<>(List.of(1, 2, 3, 4, 5, 6));
final int sum = s.reduce(0, (a, b) -> a + b);
System.out.println(sum);
// 21

Para o teste com o combinador da soma? É literalmente repetir o acumulador, só por uma questão de completude:

final Stream<Integer> s = new Stream<>(List.of(1, 2, 3, 4, 5, 6));
final int sum = s.reduce(0, (a, b) -> a + b, (a, b) -> a + b);
System.out.println(sum);
// 21

Muito bem, e para a questão do acumulador que usa a lista própria? Bem, vamos criar nosso próprio elemento de lista, o List:

public class List<T> {
    public final T head;
    public final List<T> tail;

    public List(T element) {
        this.head = element;
        this.tail = empty();
    }

    public List(T head, List<T> tail) {
        this.head = head;
        this.tail = tail;
    }

    static class EOL<T> extends List<T> {
        EOL() {
            super(null, null);
        }

        @Override
        public boolean end() {
            return true;
        }

        @Override
        public String toString() {
            return "[]";
        }

        private static final EOL<Object> SingletonEOL = new EOL<>();
    }

    public boolean end() {
        return false;
    }

    public static <T> List<T> empty() {
        return (List<T>) EOL.SingletonEOL;
    }

    @Override
    public String toString() {
        return "[" + toStringSansBrackets() + "]";
    }

    private String toStringSansBrackets() {
        if (tail.end()) {
            return "" + this.head;
        }
        return head + "," + tail.toStringSansBrackets();
    }
}

Aqui demos que necessariamente não iremos incorrer em ciclos porque os campos são todos final, então eu preciso passar para frente um List já devidamente criado e povoado (não posso referenciar ele e sobrescrever algum campo dele). Bem, se não fizerem reflexão profunda para lascar essa condição, estamos bem! E não vou entrar nessas neuras aqui.

Para exemplificar, fiz alguns experimentos:

System.out.println(new List<String>("456", new List<String>("123", empty())));
// [456,123]
System.out.println(new List<String>("123", empty()));
// [123]
System.out.println(empty());
// []

Ok, parece razoável o como ele imprime. Vamos para o exemplo, a gente inicia com a lista vazia e vai adicionando elementos como head dela:

final Stream<Integer> s = new Stream<>(List.of(1, 2, 3, 4, 5, 6));
final List<Integer> l = s.reduce(List.empty(), (acc, el) -> new List<>(el, acc), /* ??? */);
System.out.println(l);

Vamos passar um placeholder válido, não importa exatamente qual agora, ok?

E, bem, o resultado esperado:

[6,5,4,3,2,1]

Para fazer o combinador, vamos precisar mexer fortemente nessa função de concatenação. Vamos esgotar os elementos, para obter a resposta e remontar?

List<T> concat(List<T> first, List<T> second) {
    if (first.end()) {
        return second;
    }
    final T head = first.head;
    return new List<>(head, concat(first.tail, second));
}

Bem, para testar, vamos ver:

System.out.println(concat(new List<>(123, new List<>(0)), new List<>(456, new List<>(789))));
// [123,0,456,789]

Para fazer o combiner adequado:

final Stream<Integer> s = new Stream<>(List.of(1, 2, 3, 4, 5, 6));
final List<Integer> l = s.reduce(
                                    List.empty(),
                                    (acc, el) -> new List<>(el, acc),
                                    (a, b) -> concat(a, b)
                                );
System.out.println(l);

collect

Bem, aqui vamos passar para um coletor, o grosso da implementação está em Collector, que vai ser mostrado com carinho. Aqui vamos apenas passar pro coletor. Como não está sendo usado paralelismo, o combiner não vai na prática ser executado.

Mas vamos garantir que o combiner funcione! Existem dois sabores para o collect, um que passa o Collector e outro que passa os elementos lembram bastante um Collector:

Argumentos de collect:

Supplier<A> supplier
BiConsumer<A, T> acc
BiConsumer<A, A> combiner

Partes do Collector:

Supplier<A> supplier
BiConsumer<A, T> acc
BinaryOperator<A> combiner

Na descrição do terceiro argumento da função collect:

The combiner function must fold the elements from the second result container into the first result container.

Ou seja, posso transformar o BiConsumer em um BinaryOperator se eu retornar o primeiro elemento!

<T> BinaryOperator<T> toOperator(BiConsumer<T, T> consumer) {
    return (first, second) -> {
        consumer.accept(first, second);
        return first;
    };
}

Diferente da implementação padrão Java, o of vou colocar dentro do Collectors para continuar fazendo jus a não ter métodos estáticos/default em interfaces que eu estou aqui implementando, mantendo o Collector como uma interface. Então vou delegar aqui o funcionamento completo do collect com as 3 funções para quando o Collectors estiver completo.

A implementação seria algo assim:

private static <T> BinaryOperator<T> toOperator(BiConsumer<T, T> consumer) {
    return (first, second) -> {
        consumer.accept(first, second);
        return first;
    };
}

public <R> R collect(Supplier<R> supplier, BiConsumer<R, T> acc, BiConsumer<R, R> combiner) {
    return collect(Collectors.of(supplier, acc, toOperator(combiner)));
}

Então, com esse caveat em mãos, vamos implementar o collect em que se passa o Collector? No momento, irei abstrair o funcionamento do Collector (ie, simularei com o do Java).

Para começar, o Collector é um genérico do Java que tem 3 tipos:

T: o elemento que chega e é processado
R: o elemento de retorno
A: o elemento de acumulação, que em muitos casos vem com ? porque não importa pro chamador

Então, a primeira coisa a se fazer é obter um elemento de acumulação. Em seguida, precisamos seguir acumulando os elementos. Finalmente, transformamos o resultado acumulado usando um finisher:

public <A, R> R collect(Collector<T, A, R> collector) {
    A a = collector.supplier().get();
    final BiConsumer<A, T> acc = collector.accumulator();
    for (final T el: it) {
        acc.accept(a, el);
    }
    return collector.finisher().apply(a);
}

Pegando aqui o coletor summingInt:

final Stream<Integer> s = new Stream<>(List.of(1, 2, 3, 4, 5, 6));
final int l = s.collect(Collectors.summingInt(i -> i));
System.out.println(l);
// 21

De modo geral, é isso. Agora só precisaremos da implementação dos coletores na seção adequada.

empty

Retorna um iterador vazio: que não tem hasNext, e coloca como Stream:

public static <T> Stream<T> empty() {
    return new Stream<>(() -> new Iterator<>() {

        @Override
        public boolean hasNext() {
            return false;
        }

        @Override
        public T next() {
            return null;
        }
    });
}

of

Aqui vem em dois sabores: o of unitário e o com varargs. O unitário é fazer um iterator de apenas um único elemento. Já o com varargs, bem, pega até esgotar o array mesmo:

public static <T> Stream<T> of(T value) {
    return new Stream<>(() -> new Iterator<>() {
        boolean available = true;

        @Override
        public boolean hasNext() {
            return available;
        }

        @Override
        public T next() {
            available = false;
            return value;
        }
    });
}

O teste mais simples seria contar a quantidade de elementos, precisa ser necessariamente 1:

final Stream<String> s = Stream.of("valor");
final long l = s.count();
System.out.println(l);
// 1

Para a opção com varargs, é só manter o índice da posição de leitura:

@SafeVarargs
public static <T> Stream<T> of(T ...values) {
    return new Stream<>(() -> new Iterator<>() {
        int idx = 0;

        @Override
        public boolean hasNext() {
            return idx < values.length;
        }

        @Override
        public T next() {
            final T el = values[idx];
            idx++;
            return el;
        }
    });
}

Ah, sim, precisei anotar como @SafeVarargs porque tem cenários que usar varargs com genéricos causa problemas.

Para demonstração, vamos usar o Collectors.summingInt:

final Stream<Integer> s = Stream.of(1, 2, 3, 4, 5, 6);
final int l = s.collect(Collectors.summingInt(i -> i));
System.out.println(l);
// 21

concat

Existem algumas alternativas para isso. Uma delas é pegar um Stream<Stream<T>> e fazer um flatMap:

public static <T> Stream<T> concat(Stream<T> a, Stream<T> b) {
    return Stream.of(a, b).flatMap(s -> s);
}

Para testar, que tal usar o summingInt da mesma Stream.of duas vezes? Isso significa que o resultado esperado seria 42:

final Stream<Integer> s = Stream.concat(Stream.of(1, 2, 3, 4, 5, 6), Stream.of(1, 2, 3, 4, 5, 6));
final int l = s.collect(Collectors.summingInt(i -> i));
System.out.println(l);
// 42

Uma implementação mais direta disso seria um caso específico da implementação usada em flatMap: eu pego o iterador da primeira stream, levo até o fim. Quando chegar no fim, troco para o iterador da segunda stream e vou até o fim, aí acaba.

Aqui, diferente do flatMap, vou precisar me preocupar novamente com streams esgotadas ao começar. Vou adicionar variantes do teste:

2 streams cheias (igual o teste anterior)
primeira stream vazia
segunda stream vazia
ambas streams vazias

final Supplier<Stream<Integer>> stream1to6 = () -> Stream.of(1, 2, 3, 4, 5, 6);
final Stream<Integer> cheios = Stream.concat(stream1to6.get(), stream1to6.get());
final Stream<Integer> primeiroVazio = Stream.concat(Stream.empty(), stream1to6.get());
final Stream<Integer> segundoVazio = Stream.concat(stream1to6.get(), Stream.empty());
final Stream<Integer> vazios = Stream.concat(Stream.empty(), Stream.empty());

final int soma_cheios = cheios.collect(Collectors.summingInt(i -> i));
System.out.println(soma_cheios);
// 42

final int soma_primeiroVazio = primeiroVazio.collect(Collectors.summingInt(i -> i));
System.out.println(soma_primeiroVazio);
// 21

final int soma_segundoVazio = segundoVazio.collect(Collectors.summingInt(i -> i));
System.out.println(soma_segundoVazio);
// 21

final int soma_vazios = vazios.collect(Collectors.summingInt(i -> i));
System.out.println(soma_vazios);
// 0

Para eu começar usando o primeiro iterador, ele precisa ter um elemento pelo menos. A cada next eu verifico se estou usando o primeiro iterador e, se eu estiver usando ele, se ele está vazio; se for esse o caso, então eu marco que não uso mais o primeiro iterador.

public static <T> Stream<T> concat(Stream<T> a, Stream<T> b) {
    return new Stream<>(() -> new Iterator<T>() {
        private final Iterator<T> first = a.it.iterator();
        private final Iterator<T> second = b.it.iterator();

        private boolean useFirst = first.hasNext();

        private Iterator<T> getUsedIterator() {
            return useFirst? first: second;
        }
        
        @Override
        public boolean hasNext() {
            return getUsedIterator().hasNext();
        }

        @Override
        public T next() {
            final T v = getUsedIterator().next();
            
            if (useFirst && !first.hasNext()) {
                useFirst = false;
            }
            
            return v;
        }
    });
}

iterate

Surgiu no Java 9 a versão do iterate(T seed, Predicate<T> hasNext, UnaryOperator<T> next), mas vou puxar ele para cá como caso geral do iterate(T seed, UnaryOperator<T> next), que existe no Java 8. A ideia do sabor com hasNext é identificar quando precisa parar a geração de elementos. Ou seja: a versão geral precisa ser limitada de alguma maneira (normalmente com limit, ou nas APIs posteriores com takeWhile).

Assumindo a existência do sabor com hasNext, o iterate de dois elementos pode simplesmente passar um predicado tautologicamente verdade:

public static <T> Stream<T> iterate(T seed, UnaryOperator<T> next) {
    return iterate(seed, t -> true, next);
}

O funcionamento com 3 sabores é o seguinte: ele pega o elemento corrente, se passar no crivo do hasNext, retorna ele e atualiza o elemento corrente:

public static <T> Stream<T> iterate(T seed, Predicate<T> hasNext, UnaryOperator<T> next) {
    return new Stream<>(() -> new Iterator<>() {
        T curr = seed;

        @Override
        public boolean hasNext() {
            return hasNext.test(curr);
        }

        @Override
        public T next() {
            final T r = curr;
            curr = next.apply(r);
            return r;
        }
    });
}

Para testar, vamos gerar a soma de todos os elementos de 0 até um n especificado? Vamos testar para com n = 6 (esperado 21) e com n = 10 (esperado 55):

final Stream<Integer> s = Stream.iterate(0, i -> i <= n, i -> i+1);
final int l = s.collect(Collectors.summingInt(i -> i));
System.out.println(l);

generate

Bem, esse cara gera uma lista infinita. Basicamente, sempre posso criar um novo objeto chamando get:

public static <T> Stream<T> generate(Supplier<T> s) {
    return new Stream<>(() -> new Iterator<>() {
        @Override
        public boolean hasNext() {
            return true;
        }

        @Override
        public T next() {
            return s.get();
        }
    });
}

Para testar, vou fazer a soma dos primeiros 6 elementos, gerando como entrada para 6 e com 10:

final Stream<Integer> s = Stream.generate(() -> n).limit(6);
final int l = s.collect(Collectors.summingInt(i -> i));
System.out.println(l);

E isso retornou os valores esperados de 36 e 60.

builder

O método builder retorna um Stream.Builder (interface). Não preciso me ater a manter isso mas… por que não, né?

Mantendo a mesma estrutura do Stream.Builder, preciso definir ele como uma interface derivada de Consumer. A documentação diz que é mutável (até porque o método do Consumer retorna void, né?, aí não dá pra fazer sem side-effects). Então, vamos lá:

public interface Builder<T> extends Consumer<T> {
    Builder<T> add(T t);
    Stream<T> build();
}

Bom começo. Estou evitando usar os default devido a questão do retrolambda, então deixei o add como método aberto mesmo. Agora, vamos ver uma implementação pra isso?

private static class ArrayBuilder<T> implements Builder<T> {

    private final ArrayList<T> l = new ArrayList<>();

    @Override
    public Builder<T> add(T t) {
        accept(t);
        return this;
    }

    @Override
    public void accept(T t) {
        l.add(t);
    }


    @Override
    public Stream<T> build() {
        return new Stream<>(l);
    }
}

Aparentemente é isso, né? Agora, a doc diz que se tiver mudado o estado para “built”, precisa dar ruim caso sofra alguma outra alteração ou tente buildar de novo. Então, vamos botar esses safeguards?

private static class ArrayBuilder<T> implements Builder<T> {

    private final ArrayList<T> l = new ArrayList<>();
    private boolean built = false;

    @Override
    public Builder<T> add(T t) {
        accept(t);
        return this;
    }

    @Override
    public void accept(T t) {
        checkIfBuilt();
        l.add(t);
    }


    @Override
    public Stream<T> build() {
        checkIfBuilt();
        built = true;
        return new Stream<>(l);
    }
    
    private void checkIfBuilt() {
        if (built) {
            throw new IllegalStateException("já foi buildado");
        }
    }
}

E o builder?

public static <T> Builder<T> builder() {
    return new ArrayBuilder<>();
}

Implementação acessória: optional

Antes da parte mais interessante (os Collectors), vamos normalizar aqui a questão do Optional? Eles foram usados no findAny, findFirst, min e max, afinal. Como a API é a mesma, isso não foi levado em consideração antes, mas de toda sorte é necessário.

Existem algumas estratégias para isso. Uma delas é usar subclasses, Optional.None e Optional.Just. Outra é enfiar ifs em todo método. Vamos explorar ambos?

Optional observando o próprio estado

Aqui, vamos fazer o Optional olhando para ele mesmo. Sem subclasses.

O construtor é privado:

private Optional() {
    // aqui cria o optional vazio
    this.v = null;
}

private Optional(T value) {
    this.v = value;
}

Para não precisar ficar criando vazia a toda momento, vou pendurar um objeto vazio e reutilizar ele:

private static final Optional<Object> EMPTY = new Optional<>();

public static <T> Optional<T> empty() {
    return (Optional<T>) EMPTY;
}

public static <T> Optional<T> of(T v) {
    if (v == null) {
        throw new NullPointerException("aqui só aceita valor, sem nulos");
    }
    return new Optional<>(v);
}

public static <T> Optional<T> ofNullable(T v) {
    if (v == null) {
        return (Optional<T>) EMPTY;
    }
    return new Optional<>(v);
}

A implementação de equals e hashCode é direta ao assunto:

@Override
public int hashCode() {
    return v == null? 0: v.hashCode();
}

@Override
public boolean equals(Object o) {
    if (!(o instanceof Optional)) { // isso já testa o nulo
        return false;
    }
    Optional<T> other = (Optional<T>) o;
    return areEquals(this.v, other.v);
}

// basicamente uma versão de Objects.equals, porém que eu não tenho acesso nesse runtime
private static boolean areEquals(Object a, Object b) {
    if (a == null) {
        return b == null;
    }
    return a.equals(b);
}

O toString não precisa seguir nenhuma convenção explícita, mas precisam ser suficientemente distintos para não misturar:

@Override
public String toString() {
    return v == null? "Empty[]": "Valued[" + v + "]";
}

O map retorna a aplicação da função no objeto. Como pode retornar nulo, retorna com ofNullable. O flatMap eu não preciso cuidar do que é gerado, só retornar diretamente:

public <R> Optional<R> map(Function<T, R> mapper) {
    return v == null? (Optional<R>) this: Optional.ofNullable(mapper.apply(v));
}

public <R> Optional<R> flatMap(Function<T, Optional<R>> mapper) {
    return v == null? this: mapper.apply(v);
}

O filtro é interessante: se não passar no filtro, retorna EMPTY. E se tá nulo já assumimos que não passou no filtro:

public Optional<T> filter(Predicate<T> f) {
    return v == null || !f.test(v)? (Optional<T>) EMPTY : this;
}

O isPresent é direto ao assunto (semelhante ao isEmpty do Java 11):

public boolean isPresent() {
    return v != null;
}

public boolean isEmpty() {
    return v == null;
}

Agora é só o consumidor de valores, como ifPresent, orElse, essas coisas (e o quase trivial get):

public void ifPresent(Consumer<T> c) {
    if (v != null) {
        c.accept(v);
    }
}

public T get() {
    if (v == null) {
        throw new NoSuchElementException("No value present");
    }
    return v;
}

public T orElse(T t) {
    return v == null? t: v;
}

public T orElseGet(Supplier<T> s) {
    return v == null? s.get(): v;
}

public <E extends Exception> T orElseThrow(Supplier<E> s) throws E {
    if (v != null) {
        return v;
    }
    throw s.get();
}

Com subclasses

Aqui resolvemos tudo no polimorfismo. Temos as subclasses escondidas Just e None. Just possui apenas um único campo (vou chamar de v para aproveitar a implementação anterior) e None não tem campo algum, portanto podemos salvar ele do mesmo modo que usamos o EMPTY anterior (agora morando em None.EMPTY).

Sem muito segredo, boa parte do código foi simplesmente “resolver o branch” que se estava da implementação anterior, com exceção do filter para quando se tinha elemento:

public abstract class Optional<T> {

    public static <T> Optional<T> empty() {
        return (Optional<T>) None.EMPTY;
    }

    public static <T> Optional<T> of(T v) {
        if (v == null) {
            throw new NullPointerException("aqui só aceita valor, sem nulos");
        }
        return new Just<>(v);
    }

    public static <T> Optional<T> ofNullable(T v) {
        if (v == null) {
            return (Optional<T>) None.EMPTY;
        }
        return new Just<>(v);
    }

    @Override
    public abstract int hashCode();
    @Override
    public abstract boolean equals(Object o);
    @Override
    public abstract String toString();

    public abstract <R> Optional<R> map(Function<T, R> mapper);
    public abstract <R> Optional<R> flatMap(Function<T, Optional<R>> mapper);
    public abstract Optional<T> filter(Predicate<T> f);
    public abstract boolean isPresent();
    public abstract boolean isEmpty();
    public abstract void ifPresent(Consumer<T> c);
    public abstract T get();
    public abstract T orElse(T t);
    public abstract T orElseGet(Supplier<T> s);
    public abstract <E extends Exception> T orElseThrow(Supplier<E> s) throws E;
    
    
    private static class Just<T> extends Optional<T> {

        private final T v;
        private Just(T v) {
            if (v == null) {
                throw new NullPointerException("aqui só aceita valor, sem nulos");
            }
            this.v = v;
        }


        @Override
        public int hashCode() {
            return v.hashCode();
        }

        @Override
        public boolean equals(Object o) {
            if (!(o instanceof Just)) { // isso já testa o nulo
                return false;
            }
            Just<T> other = (Just<T>) o;
            return this.v.equals(other.v);
        }

        @Override
        public String toString() {
            return "Valued[" + v + "]";
        }

        @Override
        public <R> Optional<R> map(Function<T, R> mapper) {
            return Optional.ofNullable(mapper.apply(v));
        }

        @Override
        public <R> Optional<R> flatMap(Function<T, Optional<R>> mapper) {
            return mapper.apply(v);
        }

        @Override
        public Optional<T> filter(Predicate<T> f) {
            return f.test(v)? this: (Optional<T>) None.EMPTY;
        }

        @Override
        public boolean isPresent() {
            return true;
        }

        @Override
        public boolean isEmpty() {
            return false;
        }

        @Override
        public void ifPresent(Consumer<T> c) {
            c.accept(v);
        }

        @Override
        public T get() {
            return v;
        }

        @Override
        public T orElse(T t) {
            return v;
        }

        @Override
        public T orElseGet(Supplier<T> s) {
            return v;
        }

        @Override
        public <E extends Exception> T orElseThrow(Supplier<E> s) throws E {
            return v;
        }
    }
    
    private static class None<T> extends Optional<T> {

        private static final None<Object> EMPTY = new None<>();

        @Override
        public int hashCode() {
            return 0;
        }

        @Override
        public boolean equals(Object o) {
            return o instanceof None;
        }

        @Override
        public String toString() {
            return "Empty[]";
        }

        @Override
        public <R> Optional<R> map(Function<T, R> mapper) {
            return (Optional<R>) this;
        }

        @Override
        public <R> Optional<R> flatMap(Function<T, Optional<R>> mapper) {
            return (Optional<R>) this;
        }

        @Override
        public Optional<T> filter(Predicate<T> f) {
            return this;
        }

        @Override
        public boolean isPresent() {
            return false;
        }

        @Override
        public boolean isEmpty() {
            return true;
        }

        @Override
        public void ifPresent(Consumer<T> c) {
        }

        @Override
        public T get() {
            throw new NoSuchElementException("No value present");
        }

        @Override
        public T orElse(T t) {
            return t;
        }

        @Override
        public T orElseGet(Supplier<T> s) {
            return s.get();
        }

        @Override
        public <E extends Exception> T orElseThrow(Supplier<E> s) throws E {
            throw s.get();
        }
    }
}

Muito bem, funcionalmente parece correto. Agora precisamos ter uma garantia que nos era dado pelo Optional: o consumidor dessa lib não pode nem instanciar diretamente nem tampouco fazer subclasse. Ou seja, mesmo que eu implementasse todos os métodos, isso aqui na classe Main (onde moram os testes) deveria dar erro de compilação:

private static class X<T> extends Optional<T> {
    X() {
    }

    // ...
}

Mas, como eu consigo isso? Bem, meu primeiro experimento foi colocar construtor privado vazio em Optional:

public abstract class Optional<T> {

    private Optional() {
    }

    // ...
}

E, bem, isso manteve a compilação funcionando adequadamente dentro da mesma unidade de compilação! Ufa… E, sim, para fora da unidade de compilação passou a dar problema, com a mensagem de erro:

There is no no-arg constructor available in ‘Optional’

Variações de subclasses?

Será que eu posso fazer essas implementações com a subclasse não sendo uma nested class? Isto é, algo assim:

public abstract class Optional<T> {
    private Optional() {
    }

    // ...
}

class None extends Optional<T> {
    // ?
}

E a resposta é não. Dá o mesmíssimo erro. Colocar duas classes no root level é mais ou menos equivalente a ter separado em dois arquivos. Só que apenas uma das classes pode ser pública (pela JLS apenas a que tem o mesmo nome do arquivo que pode ser pública, JLS §7.6).

Para permitir esse tipo de implementação, eu precisaria deixar o nível de acesso do construtor de Optional para package private. Ou seja: qualquer um poderia ter uma classe no pacote com.jeffque (ou o nome de pacote escolhido) e fazer uma subclasse. O que fere a intenção de proibir todo mundo de conseguir fazer subclasse (lembrando que não tenho sealed aqui devido às restrições).

E com classe anônima? Bem, na real daria quase certo sim. Só teríamos problemas no equals. E como se resolveria isso? Bem, vamos tentar?

Para simplificar, vou criar uma classe de experimento chamada de Xp. Tal qual o Optional, ela vai ser genérica e abstrata com o construtor privado. Para implementar o equals, vou assumir algo relativamente ok e aceitável: que vamos ter um singleton do EMPTY. Com isso, só é igual se for igual via igualdade de referência:

public abstract class Xp<T> {
    
    @Override
    public abstract boolean equals(Object obj);
    @Override
    public abstract int hashCode();
    @Override
    public abstract String toString();

    private Xp() {
    }
    
    private static final Xp<Object> EMPTY = new Xp<>() {

        @Override
        public boolean equals(Object obj) {
            return this == obj;
        }

        @Override
        public int hashCode() {
            return 0;
        }

        @Override
        public String toString() {
            return "Empty[]";
        }
    };
    
    public static <T> Xp<T> empty() {
        return (Xp<T>) EMPTY;
    }   
}

Ok, para terminar as factories, vamos implementar o of e ofNullable (por hora o of como um placeholder):

public static <T> Xp<T> ofNullable(T v) {
    if (v == null) {
        return empty();
    }
    return of(v);
}

public static <T> Xp<T> of(T v) {
    if (v == null) {
        throw new NullPointerException("aqui só aceita valor, sem nulos");
    }
    return new Xp<T>() {
        @Override
        public int hashCode() {
            return v.hashCode();
        }

        @Override
        public boolean equals(Object obj) {
            return false;
        }

        @Override
        public String toString() {
            return "Value[" + v + "]";
        }
    };
}

Até aqui, tudo bem, preciso garantir o funcionamento do equals. Pegando via clausura eu sei que não vai ser possível obter o valor v de nenhum jeito, portanto vamos criar um campo pra ele:

public static <T> Xp<T> of(T value) {
    if (value == null) {
        throw new NullPointerException("aqui só aceita valor, sem nulos");
    }
    return new Xp<T>() {

        final T v = value;

        @Override
        public int hashCode() {
            return v.hashCode();
        }

        @Override
        public boolean equals(Object obj) {
            return false;
        }

        @Override
        public String toString() {
            return "Value[" + v + "]";
        }
    };
}

Ok, assim eu tenho um campo v. Será que eu consigo fazer um cast para a classe anônima? Bem, usando apenas a sintaxe java? Não. Mas eu posso pegar a classe daquele objeto específico e tentar, né? Eu não tenho nenhum tipo para segurar a variável, então eu preciso fazer inline o class.cast() e pegar o campo. Bora tentar?

@Override
public boolean equals(Object obj) {
    if (obj == null) {
        return false;
    }
    if (!this.getClass().isInstance(obj)) {
        return false;
    }
    return this.getClass().cast(obj).v.equals(this.v);
}

Primeiro, verifico que não é nulo. Então, verifico que é da instancia da minha classe anônima. E então eu faço o cast do objeto e pego seu campo para comparar com a minha variável local!

Ok, além disso, temos outra opção? Podemos procurar pelo campo via reflection, que tal?

@Override
public boolean equals(Object obj) {
    if (obj == null) {
        return false;
    }
    if (!(obj instanceof Xp)) {
        return false;
    }
    final Xp<?> other = (Xp<?>) obj;
    try {
        final Field field = other.getClass().getDeclaredField("v");
        final Object otherV = field.get(other);
        return otherV.equals(this.v);
    } catch (NoSuchFieldException | IllegalAccessException e) {
        return false;
    }
}

Note que, caso eu faça algo como Xp.of("str").equals(Xp.empty()) é necessário que eu pegue o NoSuchFieldException, pois a classe do empty() não tem de fato o campo v.

Como questão de experimento, resolvi colocar um breakpoint para examinar os objetos em mão, e obtive coisas peculiares:

o IntelliJ está acusando os objetos de terem o campo v e o campo value, que foi pegue via clausura
o evaluate reclama quando eu peço other.v, mas mostra o resultado
o evaluate se recusa a trabalhar com other.value

Aqui o acesso para other.v:

Aqui o acesso para other.value:

Hmmm, fiquei com um gostinho de que eu consigo me livrar do singleton. Será? Bora testar simplesmente verificar se o objeto é instância de this.getClass()?

@Override
public boolean equals(Object obj) {
    return this.getClass().isInstance(obj);
}

Et voilà! Tudo certo! Alguns experimentos que eu fiz com essas variações:

final Xp<String> one = Xp.of("one");
final Xp<String> uno = Xp.of("one");
final Xp<Integer> unonumber = Xp.of(1);
final Xp<Integer> duonumber = Xp.of(2);
final Xp<String> empty = Xp.empty();

System.out.println("one x uno: " + one.equals(uno));
System.out.println("one x unon: " + one.equals(unonumber));
System.out.println("duon x unon: " + duonumber.equals(unonumber));
System.out.println("uno x empty: " + uno.equals(empty));
System.out.println("empty x empty: " + empty.equals(empty));
System.out.println("empty x uno: " + empty.equals(uno));

System.out.println("empty x null: " + empty.equals(null));

Parte mais interessante: os coletores

Um coletor, de modo geral, ele se separa em 4 níveis:

um iniciador do acumulador
uma função de acumulação (pega um elemento T e mistura com o acumulador)
uma função de combinação (dados dois acumuladores, como combiná-los)
um finalizador (transforma o acumulador em resultado final)

Muitas vezes (nem sempre) o acumulador é do mesmo tipo do resultado final, então nesses casos o finalizador é a função identidade. As duas factories que tem na JavaDoc indicam exatamente isso: uma retorna um Collector<T, A, R> e a outra um Collector<T, R, R>.

Dito isso, e dado o compromisso de que não iremos usar métodos estáticos em interfaces, o Collector daqui vai ser só a interface com métodos abertos e as factories vão precisar residir em Collectors. E como não lidamos com as características das streams, também não vou implementar isso para os coletores:

public interface Collector<T, A, R> {

    Supplier<A> supplier();
    BiConsumer<A, T> accumulator();
    BinaryOperator<A> combiner();
    Function<A, R> finisher();
}

E as implementações das factories são resultados derivados diretamente disso, tanto o caso do coletor sem um finalizador próprio como o que implementa tudo:

public final class Collectors {

    public static <T, A, R> Collector<T, A, R> of(Supplier<A> supplier, BiConsumer<A,T> acc, BinaryOperator<A> combiner, Function<A, R> finisher) {
        return new Collector<>() {
            @Override
            public Supplier<A> supplier() {
                return supplier;
            }

            @Override
            public BiConsumer<A, T> accumulator() {
                return acc;
            }

            @Override
            public BinaryOperator<A> combiner() {
                return combiner;
            }

            @Override
            public Function<A, R> finisher() {
                return finisher;
            }
        };
    }

    public static <T, R> Collector<T, R, R> of(Supplier<R> supplier, BiConsumer<R,T> acc, BinaryOperator<R> combiner) {
        return of(supplier, acc, combiner, i -> i);
    }
}

Para exemplificar o teste, vou transformar um coletor arbitrário do Java em um coletor próprio para a minha implementação:

static <T, A, R> Collector<T, A, R> toMyCollector(java.util.stream.Collector<T, A, R> collector) {
    return Collectors.of(
        collector.supplier(),
        collector.accumulator(),
        collector.combiner(),
        collector.finisher()
    );
}

E com isso eu consigo aproveitar os testes feitos sobre Stream#concat:

final Supplier<Stream<Integer>> stream1to6 = () -> Stream.of(1, 2, 3, 4, 5, 6);
final Stream<Integer> cheios = Stream.concat(stream1to6.get(), stream1to6.get());
final Stream<Integer> primeiroVazio = Stream.concat(Stream.empty(), stream1to6.get());
final Stream<Integer> segundoVazio = Stream.concat(stream1to6.get(), Stream.empty());
final Stream<Integer> vazios = Stream.concat(Stream.empty(), Stream.empty());

final int soma_cheios = cheios.collect(toMyCollector(java.util.stream.Collectors.summingInt(i -> i)));
System.out.println(soma_cheios);
// 42

final int soma_primeiroVazio = primeiroVazio.collect(toMyCollector(java.util.stream.Collectors.summingInt(i -> i)));
System.out.println(soma_primeiroVazio);
// 21

final int soma_segundoVazio = segundoVazio.collect(toMyCollector(java.util.stream.Collectors.summingInt(i -> i)));
System.out.println(soma_segundoVazio);
// 21

final int soma_vazios = vazios.collect(toMyCollector(java.util.stream.Collectors.summingInt(i -> i)));
System.out.println(soma_vazios);
// 0

Ok, prova de conceito de que funciona tá ok. Hora de implementar os demais coletores em termos de Collectors.of!

Uma observação importante é que, para efeito de quem vai consumir o coletor, saber quem é o acumulador do coletor é detalhe de implementação irrelevante, até porque ele é usado apenas internamente e não é exposto ao mundo externo, por isso que a maioria dos coletores são apresentados como Collector<T, ?, R>, onde o elemento de entrada T é importante e o elemento retornado R também é importante. O meio do caminho? Não.

toList, toSet, toCollection

Aqui eu agrupei esses por um bom motivo:

public static <T> Collector<T, ?, List<T>> toList() {
    return toCollection(ArrayList::new);
}

public static <T> Collector<T, ?, Set<T>> toSet() {
    return toCollection(HashSet::new);
}

Como na documentação sobre o toList e toSet não é especificado nenhuma capacidade da coleção sendo retornada, estou tranquilo de que ela pode fazer qualquer coisa, até ser mutável. Do javadoc do toSet:

There are no guarantees on the type, mutability, serializability, or thread-safety of the Set returned

Para fazer isso, basicamente é adicionar elemento a coleção no acumulador e pegar o toOperator que foi usado pra transformar um BiConsumer em um BinaryOperator:

public static <T, C extends Collection<T>> Collector<T, ?, C> toCollection(Supplier<C> supplier) {
    return of(supplier, Collection::add, toOperator(Collection<T>::addAll));
}

joining

Aqui só vamos juntar strings. São 3 sabores de joining:

um que só junta tudo
um que coloca um separador
o final que coloca um prefixo e um sufixo além do separador

Podemos modelar como o que só junta é uma chamada para o separador, porém que usa o separador string vazia. E finalmente o que usa o separador chama o sabor completo porém passando string vazia para sufixo e prefixo:

public static Collector<String, ?, String> joining() {
    return joining("");
}

public static Collector<String, ?, String> joining(String delim) {
    return joining(delim, "", "");
}

Muito bem, agora vamos fazer a versão completa. Não vou me preocupar com otimizações, só API. Infelizmente o accumulator é um BiConsumer, não um BiFunction. Ou seja, vai ser de toda sorte necessário ter uma estrutura mutável (não posso simplesmente fazer operações de string). Então vamos usar como elemento de acumulação um container de string! Uma variável cuja única função é ter uma string, e que eu possa trocar essa string. Para facilitar essa troca, vou colocar os métodos acc que recebe uma string e altera o seu conteúdo, e o combiner que recebe outro elemento do mesmo tipo e combina.

Tanto no acc quanto no combiner colocamos o delimitador, exceto se ainda não tiver sido inicializado. Se não tiver sido inicializado, só aceita a nova string no lugar sem colocar nada. Para fazer isso, vou chamar essa estrutura de StringHolder. Ele vai ter um construtor vazio e os métodos acc e combine, onde acc recebe uma nova string e combine recebe outro StringHolder:

public static Collector<String, ?, String> joining(String delim, String preffix, String suffix) {
    class StringHolder {
        boolean initialized = false;
        String v = "";
        StringHolder() {
        }

        void acc(String s) {
            if (!initialized) {
                initialized = true;
                this.v = s;
                return;
            }
            this.v += delim + s;
        }

        StringHolder combine(StringHolder other) {
            if (!initialized) {
                if (!other.initialized) {
                    return this;
                } else {
                    this.acc(other.v);
                    return this;
                }
            } else if (other.initialized) {
                this.acc(other.v);
                return this;
            }
            return this;
        }

        String finish() {
            return preffix + v + suffix;
        }
    }
    return of(
        StringHolder::new,
        StringHolder::acc,
        StringHolder::combine,
        StringHolder::finish
    );
}

Para testes:

System.out.println(
    Stream.<String>empty().collect(Collectors.joining(", ", "[", "]"))
);
// []
System.out.println(
    Stream.of(1, 2, 3, 4).map(s -> "" + s).collect(Collectors.joining(", ", "[", "]"))
);
// [1, 2, 3, 4]

E imprimiu conforme esperado. Agora, a lógica do combine me parece exagerada. Hmmm, vamos examinar uma coisinha…

Se ambos estão não inicializados, então preciso retornar um elemento não inicializado também, e aqui o this é um ótimo candidato (eles são indistinguíveis nesse estado). Agora, se o elemento que eu estiver recebendo esteja inicializado, então preciso causar os efeitos colaterais no elemento corrente, marcando ele como inicializado e “acumulando” o que vier do outro acumulador.

Por fim, não tem o que fazer com o valor atual pois o outro elemento não foi inicializado, então posso retornar this sem maiores complicações:

StringHolder combine(StringHolder other) {
    if (!initialized && !other.initialized) {
        return this;
    } else if (other.initialized) {
        this.acc(other.v);
        return this;
    }
    return this;
}

Mas lendo agora percebi que é mais simples ainda: eu preciso alterar o estado do this apenas se o outro já tiver sido inicializado. Caso contrário, retorno diretamente o que já temos:

StringHolder combine(StringHolder other) {
    if (other.initialized) {
        this.acc(other.v);
        return this;
    }
    return this;
}

mapping

Aqui a intenção é mapear antes de passar para um outro coletor. Por exemplo, eu não posso passar diretamente uma stream de inteiros para o Collectors.joining(), mas eu posso mapear o inteiro em uma string e adaptar isso para o Collectors.joining():

Collectors.mapping(i -> "" + i, Collectors.joining(", "));

De certo modo, vamos decorar o accumulator do coletor passado como argumento, de modo que a entrada que se ele aceita (A, U), vamos passar (A, T) e a função T => U. O resto não se altera.

Então, vamos aplicar o padrão de projeto decorator?, tal qual temos no post Funções como padrões de projeto: do GoF pro Computaria (especificamente o sabor “Estou ativamente escolhendo passar os argumentos para a função não decorada” descritos para decorator):

public static <T, A, U, R> Collector<T, ?, R> mapping(Function<T, U> mapper, Collector<U, A, R> baseCollector) {
    final BiConsumer<A, T> baseAcc = baseCollector.accumulator();
    return of(
        baseCollector.supplier(),
        (a, t) -> baseAcc.accept(a, mapper.apply(t)),
        baseCollector.combiner(),
        baseCollector.finisher()
    );
}

Para testar, vou pegar o exemplo do joining só que, no lugar de mapear usando operações intermediárias de stream pra coletar depois, vou fazer tudo usando apenas Collectors.mapping:

System.out.println(
    Stream
        .of(1, 2, 3, 4)
        .collect(Collectors.mapping(s -> "" + s, Collectors.joining(", ", "[", "]")))
);
// [1, 2, 3, 4]

E o funcionamento foi adequadamente.

collectingAndThen

De modo semelhante ao mapping, o collectingAndThen tem a pegada de ser uma alteração feito em outro coletor. Mas aqui a mudança ocorre no final: o finisher passa a ser transformado em outra coisa depois. Para exemplificar o desafio, vou pegar a coleção do exemplo do mapping e vou aplicar a função String::length para obter um inteiro:

System.out.println(
    Stream
        .of(1, 2, 3, 4)
        .collect(
            Collectors.collectingAndThen(
                Collectors.mapping(s -> "" + s, Collectors.joining(", ", "[", "]")),
                String::length
            )
        )
);
// 12

Basicamente, vou montar um coletor tal qual meu coletor base, porém vou decorar a saída do finisher original do coletor:

public static <T, A, R, RR> Collector<T, ?, RR> collectingAndThen(Collector<T, A, R> baseCollector, Function<R, RR> finisher) {
    return of(
        baseCollector.supplier(),
        baseCollector.accumulator(),
        baseCollector.combiner(),
        a -> finisher.apply(baseCollector.finisher().apply(a))
    );
}

E o teste executa perfeitamente, sem maiores repercussões. Note que se eu tivesse acesso a métodos default das interfaces eu faria composição de função no lugar dessa linha gigantesca em que a ordem de leitura respeitasse a ordem de chamada de funções:

-a -> finisher.apply(baseCollector.finisher().apply(a))
+baseCollector.finisher().andThen(finisher)

counting

Esse é bem… tosco. Basicamente faz algo semelhante ao Stream.count, mas a nível de coletor.

Basicamente começo com 0 elementos encontrados, o acumulador incrementa o que encontrei e o combiner soma o que encontrei, e por fim eu retorno apenas o que encontrei descartando o holder:

public static <T> Collector<T, ?, Long> counting() {
    class Holder {
        long c = 0;

        long c() {
            return c;
        }

        void inc() {
            c++;
        }

        Holder add(long a) {
            c += a;
            return this;
        }
    }
    return of(
        Holder::new,
        (h, v) -> h.inc(),
        (h1, h2) -> h1.add(h2.c),
        Holder::c
    );
}

Um caso de uso para ele? Bem, tem situações que eu não recebo nenhuma stream e mesmo assim eu preciso contar. Como, por exemplo, saber quantos elementos tem a mesma chave: posso usar o groupingBy seguido de counting como o coletor que vai lidar com “o que fazer com os elementos que tem a mesma chave de agrupamento”.

groupingBy

Esse coletor tem 3 sabores:

o primeiro determina como separar os agrupamentos
o segundo determina como lidar com a acumulação
o terceiro permite criar o mapa que vai ser usado para juntar as coisas

No primeiro sabor, eu posso simplesmente delegar para o segundo passando o coletor toList:

public static <T, K> Collector<T, ?, Map<K, List<T>>> groupingBy(Function<T, K> classifier) {
    return groupingBy(classifier, toList());
}

Para o caso em que se fornece o coletor para lidar com a acumulação dentro de um mesmo agrupamento, posso simplesmente delegar adiante a criação de um HashMap e ser feliz:

public static <T, K, A, D> Collector<T, ?, Map<K, D>> groupingBy(Function<T, K> classifier, Collector<T, A, D> downstream) {
    return groupingBy(classifier, HashMap::new, downstream);
}

E agora finalmente vamos à magia! O sabor completo!

Ok, para agrupar, vamos usar um… HashMap… só que de K -> A (chave para o intermediário de acumulação do coletor downstream) no lugar de K -> D, que é o tipo retornado pelo mapSupplier:

public static <T, K, A, D, M extends Map<K, D>> Collector<T, ?, M> groupingBy(Function<T, K> classifier,
                                                                              Supplier<M> mapSupplier,
                                                                              Collector<T, A, D> downstream) {
    //...
}

O finish vou pegar os valores guardados no HashMap intermediário e adicionar no map fornecido, finalizando os valores acumulados:

M finish() {
    final M ret = mapSupplier.get();
    final Function<A, D> finishAcc = downstream.finisher();
    
    for (Map.Entry<K, A> entry: intermediary.entrySet()) {
        ret.put(entry.getKey(), finishAcc.apply(entry.getValue()));
    }
    return ret;
}

Ok, essa foi a parte mais fácil… e para combinar dois valores? Que tal iterar no mapa do outro elemento recebido e, se existir elemento no mapa do this, acumular e substituir esse elemento?

Holder combine(Holder other) {
    for (Map.Entry<K, A> entry: other.intermediary.entrySet()) {
        final K key = entry.getKey();
        final A v = entry.getValue();
        if (this.intermediary.containsKey(key)) {
            final A prevValue = this.intermediary.get(key);
            final A newValue = downstream.combiner().apply(prevValue, v);
            this.intermediary.put(key, newValue); // substituindo o valor atual
        } else {
            this.intermediary.put(key, v);
        } 
    }
    return this;
}

E para receber o elemento? Bem, podemos verificar se ele tem a chave. Tendo, eu acumulo com o novo elemento. Não tendo, insiro um novo acumulador fornecido pelo downstream.supplier().get() e acumulo com o novo elemento:

void acc(T el) {
    final K key = classifier.apply(el);
    final A accUntil;
    if (!intermediary.containsKey(key)) {
        accUntil = downstream.supplier().get();
        intermediary.put(key, accUntil);
    } else {
        accUntil = intermediary.get(key);
        
    }
    downstream.accumulator().accept(accUntil, el);
}

E fica assim a visão geral:

public static <T, K, A, D, M extends Map<K, D>> Collector<T, ?, M> groupingBy(Function<T, K> classifier,
                                                                              Supplier<M> mapSupplier,
                                                                              Collector<T, A, D> downstream) {
    class Holder {
        final HashMap<K, A> intermediary = new HashMap<>();
        
        void acc(T el) {
            final K key = classifier.apply(el);
            final A accUntil;
            if (!intermediary.containsKey(key)) {
                accUntil = downstream.supplier().get();
                intermediary.put(key, accUntil);
            } else {
                accUntil = intermediary.get(key);
                
            }
            downstream.accumulator().accept(accUntil, el);
        }
        
        Holder combine(Holder other) {
            for (Map.Entry<K, A> entry: other.intermediary.entrySet()) {
                final K key = entry.getKey();
                final A v = entry.getValue();
                if (this.intermediary.containsKey(key)) {
                    final A prevValue = this.intermediary.get(key);
                    final A newValue = downstream.combiner().apply(prevValue, v);
                    this.intermediary.put(key, newValue);
                } else {
                    this.intermediary.put(key, v);
                } 
            }
            return this;
        }
        
        M finish() {
            final M ret = mapSupplier.get();
            final Function<A, D> finishAcc = downstream.finisher();
            
            for (Map.Entry<K, A> entry: intermediary.entrySet()) {
                ret.put(entry.getKey(), finishAcc.apply(entry.getValue()));
            }
            return ret;
        }
    }
    return Collectors.of(
        Holder::new,
        Holder::acc,
        Holder::combine,
        Holder::finish
    );
}

Para testar, vamos agrupar em par/ímpar?

final Stream<Integer> s = Stream.iterate(0, i -> true, i -> i + 1).limit(6).flatMap(i -> Stream.of(i, i));
final Map<Integer, List<Integer>> m = s.collect(Collectors.groupingBy(a -> a % 2));
System.out.println(m);
// 0: [0, 0, 2, 2]
// 1: [1, 1, 3, 3, 5, 5]

O terceiro sabor nem me interessa tanto, mas também podemos acumular contando, né? O caso de uso até mencionado na seção anterior!

final Stream<Integer> s = Stream.iterate(0, i -> true, i -> i + 1).limit(6).flatMap(i -> Stream.of(i, i));
final Map<Integer, Integer> m = s.collect(Collectors.groupingBy(a -> a % 2, Collectors.counting()));
System.out.println(m);
// 0: 4
// 1: 6

maxBy/minBy

Praticamente tão sem graça quanto o counting anterior. Tem o mesmo caso de uso e historinha motivadora: tem coisa de stream que é obviamente muito similar, porém tem situações que eu não terei stream.

Para motivar, no lugar de contar quantos elementos tem após agrupar usando o groupingBy, vou querer o elemento máximo/mínimo desse agrupamento. Como diferença eu tenho que talvez o meu Holder não tenha sido ainda inicializado, situação em que retorna um Optional.empty().

public static <T> Collector<T, ?, Optional<T>> maxBy(Comparator<T> comparator) {
    class Holder {
        T max;
        boolean initialized = false;

        Optional<T> get() {
            if (!initialized) {
                return Optional.empty();
            }
            return Optional.of(max);
        }

        void acc(T t) {
            if (!initialized) {
                initialized = true;
                max = t;
                return;
            }
            if (comparator.compare(max, t) < 0) {
                max = t;
            }
        }

        Holder combine(Holder other) {
            if (other.initialized) {
                this.acc(other.max);
            }
            return this;
        }
    }
    return of(
        Holder::new,
        Holder::acc,
        Holder::combine,
        Holder::get
    );
}

O minBy segue a mesma lógica, só trocando com o que estou verificando o retorno do Comparator:

public static <T> Collector<T, ?, Optional<T>> minBy(Comparator<T> comparator) {
    class Holder {
        T min;
        boolean initialized = false;

        Optional<T> get() {
            if (!initialized) {
                return Optional.empty();
            }
            return Optional.of(min);
        }

        void acc(T t) {
            if (!initialized) {
                initialized = true;
                min = t;
                return;
            }
            if (comparator.compare(min, t) > 0) {
                min = t;
            }
        }

        Holder combine(Holder other) {
            if (other.initialized) {
                this.acc(other.min);
            }
            return this;
        }
    }
    return of(
        Holder::new,
        Holder::acc,
        Holder::combine,
        Holder::get
    );
}

partitioningBy

Aqui o primeiro sabor do partitioningBy eu posso simplesmente dizer que é um groupingBy com o booleano da função de particionamento:

public static <T> Collector<T, ?, Map<Boolean, List<T>>> partitioningBy(Predicate<T> predicate) {
    return groupingBy(predicate::test);
}

mas… eu poderia lidar melhor com isso, não poderia? Posso guardar em duas listas aqueles que atendem ao requisito de teste e os que não atendem, e só no final criar um HashMap (por exemplo) com TRUE e FALSE e inserir essas listas:

public static <T> Collector<T, ?, Map<Boolean, List<T>>> partitioningBy(Predicate<T> predicate) {
    class Holder {
        final ArrayList<T> atende = new ArrayList<>();
        final ArrayList<T> naoAtende = new ArrayList<>();

        void acc(T t) {
            final ArrayList<T> alvo = predicate.test(t)? atende: naoAtende;
            alvo.add(t);
        }

        Holder combine(Holder other) {
            atende.addAll(other.atende);
            naoAtende.addAll(other.naoAtende);
            return this;
        }

        Map<Boolean, List<T>> finish() {
            final HashMap<Boolean, List<T>> r = new HashMap<>();
            r.put(Boolean.TRUE, atende);
            r.put(Boolean.FALSE, naoAtende);

            return r;
        }
    }
    return of(
        Holder::new,
        Holder::acc,
        Holder::combine,
        Holder::finish
    );
}

Até aqui tá legal. Mas falta o outro sabor do partitioningBy: o que recebe a função de partição e também o que fazer com os elementos que chegam lá. Nesse sentido, o mais fácil é delegar para o groupingBy passando o coletor para ele:

public static <T, D, A> Collector<T, ?, Map<Boolean, D>> partitioningBy(Predicate<T> predicate, Collector<T, A, D> baseCollector) {
    return groupingBy(predicate::test, baseCollector);
}

Mas eu posso adaptar a solução de cima também, né? Só que no lugar de usar ArrayList<T> como elemento acumulador, passo a usar A. E no finish, eu aplico o baseCollector.finisher() nos atende e naoAtende:

public static <T, D, A> Collector<T, ?, Map<Boolean, D>> partitioningBy(Predicate<T> predicate, Collector<T, A, D> baseCollector) {

    class Holder {
        A atende = baseCollector.supplier().get();
        A naoAtende = baseCollector.supplier().get();

        void acc(T t) {
            final A alvo = predicate.test(t)? atende: naoAtende;
            baseCollector.accumulator().accept(alvo, t);
        }

        Holder combine(Holder other) {
            atende = baseCollector.combiner().apply(atende, other.atende);
            naoAtende = baseCollector.combiner().apply(naoAtende, other.naoAtende);
            return this;
        }

        Map<Boolean, D> finish() {
            final HashMap<Boolean, D> r = new HashMap<>();
            r.put(Boolean.TRUE, baseCollector.finisher().apply(atende));
            r.put(Boolean.FALSE, baseCollector.finisher().apply(naoAtende));

            return r;
        }
    }
    return of(
        Holder::new,
        Holder::acc,
        Holder::combine,
        Holder::finish
    );
}

E sabe uma coisa que seria divertida? Escrever o primeiro sabor do paritioningBy como chamando o segundo sabor:

public static <T> Collector<T, ?, Map<Boolean, List<T>>> partitioningBy(Predicate<T> predicate) {
    return partitioningBy(predicate, Collectors.toList());
}

Para testar, vou particionar os elementos como pares e ímpares. Para o caso do segundo sabor, no lugar de esperar por uma lista, vou simplesmente querer contar:

System.out.println(
    Stream.of(1, 2, 3, 4).collect(Collectors.partitioningBy(i -> i % 2 == 0))
);
// { false = [1, 3], true = [2, 4]}

System.out.println(
    Stream.of(1, 2, 3, 4).collect(Collectors.partitioningBy(i -> i % 2 == 0, Collectors.counting()))
);
// { false = 2, true = 2}

reducing

Aqui a redução vem em 3 sabores:

através da mistura de dois elementos, retornando “vazio” caso não tenha nada para misturar
mesma coisa do anterior, porém com um elemento neutro/identidade
a identidade é de tipo diferente dos elementos e tem uma função que mapeia do elemento recebido para o tipo da identidade (que é o tipo do retorno), e a mistura ocorre no tipo da mistura

Vamos começar com o modelo que recebe a identidade e a função de alteração? Seguindo os exemplos com seus respectivos Holders, começo com o elemento neutro, depois atualizo o Holder a cada elemento novo recebido; e caso precise combinar dois Holders? Só mistura os elementos deles e retorna this:

public static <T> Collector<T, ?, T> reducing(T identity, BinaryOperator<T> op) {
    class Holder {
        T el = identity;
        
        void acc(T another) {
            el = op.apply(el, another);
        }
        
        Holder combine(Holder o) {
            el = op.apply(el, o.el);
            return this;
        }
        
        T finish() {
            return el;
        }
    }
    return Collectors.of(
        Holder::new,
        Holder::acc,
        Holder::combine,
        Holder::finish
    );
}

Ok, e para o caso que precisa aplicar a função que mapeia? Bem, podemos transformar o caso anterior nesse… se eu disser que a função que mapeia é a função identidade!

public static <T> Collector<T, ?, T> reducing(T identity, BinaryOperator<T> op) {
    return reducing(identity, i -> i, op);
}

O código é praticamente igual, porém eu aplico a função de mapeamento antes de misturar:

public static <T, R> Collector<T, ?, R> reducing(R identity, Function<T, R> mapping, BinaryOperator<R> op) {
    class Holder {
        R el = identity;

        void acc(T another) {
            el = op.apply(el, mapping.apply(another));
        }

        Holder combine(Holder o) {
            el = op.apply(el, o.el);
            return this;
        }

        R finish() {
            return el;
        }
    }
    return Collectors.of(
        Holder::new,
        Holder::acc,
        Holder::combine,
        Holder::finish
    );
}

Certo, e quanto a opção que retorna “vazio” na ausência de valores? Esse “vazio” é indicado por Optional.empty(). Eu poderia fazer uma volta pra fazer colapsar no terceiro sabor ali acima, que acabamos de descrever… ou então simplesmente assumir que tá tudo bem fazer outra implementação porque é mais simples!

Aqui, o Holder precisa identificar se já foi usado, tal qual foi feito para o joining. A cascata também é a mesma, mas tem um jeito mais simples de escrever que não percebi na escrita original do joining:

se ambos foram inicializados, faz a junção dos valores
se apenas o do lado direito foi inicializado, sobrescreve os valores do lado esquerdo (o this) com as coisas do lado direito
retorna this que vai estar com os valores mais atuais

No caso do finisher, eu verifico se foi inicializado. Se não foi, retorna o Optional.empty. Caso já foi inicializado, retorna Optional.ofNullable do valor acumulado:

public static <T> Collector<T, ?, Optional<T>> reducing(BinaryOperator<T> op) {
    class Holder {
        boolean started = false;
        T el = null;

        void acc(T another) {
            if (!started) {
                el = another;
                started = true;
            } else {
                el = op.apply(el, another);
            }
        }

        Holder combine(Holder o) {
            if (this.started && o.started) {
                el = op.apply(el, o.el);
            } else if (o.started) {
                this.started = true;
                this.el = o.el;
            }
            return this;
        }

        Optional<T> finish() {
            if (started) {
                return Optional.ofNullable(el);
            }
            return Optional.empty();
        }
    }
    return Collectors.of(
        Holder::new,
        Holder::acc,
        Holder::combine,
        Holder::finish
    );
}

Se eu quisesse transformar esse versão em um dos outros sabores, precisaria necessariamente usar o terceiro sabor: o tipo de retorno não é o mesmo tipo do dado que entra. Mas… será mesmo? Vamos examinar?

Quando fazemos o reducing com apenas o operador de redução, se a lista tiver apenas um único elemento, esse elemento é retornado, sem nunca chamar a função que faz a acumulação. Portanto, é necessário fazer a distinção se já começou a acumular ou não (que no holder logo acima é a variável started).

Isso foi possível simular desse jeito em uma stream Java com um coletor Java tradicional:

// java.util.stream.Stream<Integer> s = ...;
System.out.println(s.limit(1).collect(java.util.stream.Collectors.reducing((a, b) -> {
    System.out.println("no acumulador " + (a + b));
    return a + b;
})));

Em nenhum momento o System.out é chamado aqui. Então para fazer isso eu preciso de uma maneira de identificar que o primeiro elemento não foi usado. Então… que tal… alterar o finisher? Vamos fazer um reducer que vai adaptar a chamada adequada? Vou expressar em TypeScript porque acho mais adequado para fazer sum-types:

function reducer<T>(lhs: NEUTRAL | Optional<T>, rhs: Optional<T>): Optional<T> {
    // ...
}

E para o operador de redução que vou de fato encadear? Bem, só vou chamar ele caso o meu elemento da esquerda não seja o NEUTRAL, e vou abrir os Optional claro (com null no padrão):

type Reducer<T> = (lhs: NEUTRAL | Optional<T>, rhs: Optional<T>) => Optional<T>;

function fromOperatorReducer2reducer<T>(op: (lhs: T | null, rhs: T | null) => T | null): Reducer<T> {
    return (lhs: NEUTRAL | Optional<T>, rhs: Optional<T>) => {
        if (lhs == NEUTRAL) {
            return rhs;
        }
        // portanto, agora lhs é Optional<T>
        const lhsv = lhs.orElse(null);
        const rhsv = rhs.orElse(null);
        return Optional.ofNullable(lhsv, rhsv);
    }
}

Preciso identificar só a questão do elemento chamado de NEUTRAL. Para o caso de por acaso a lista estar vazia, preciso adaptar o finisher para transformar o NEUTRAL em Optional.empty. Esse processo é conhecido por ser “coletar e então”, ou collectingAndThen! Quando se toma uma ação após a coleta terminar.

Vamos fazer isso em Java agora?

public static <T> Collector<T, ?, Optional<T>> reducing(BinaryOperator<T> op) {
    final Object NEUTRAL = new Object(); 
    return Collectors.collectingAndThen(reducing(NEUTRAL, Optional::ofNullable, (a, b) -> {
        // aqui para o java tanto a quanto b são Object, mas eu sei que o b foi gerado com o mapper
        if (a == NEUTRAL) {
            return b;
        }

        // como java não conhece bem sum-types, preciso fazer o casting na mão
        final Optional<T> ao = (Optional<T>) a;
        final Optional<T> bo = (Optional<T>) b;
        final T av = ao.orElse(null);
        final T bv = bo.orElse(null);
        return Optional.ofNullable(op.apply(av, bv));
    }), a -> a == NEUTRAL? Optional.empty(): (Optional<T>) a);
}

O teste disso aqui, como podemos conferir os resultados? Bem, vamos começar com um cara que gera streams de modo unificado, assim podemos validar os diversos sabores rapidamente para a mesma stream:

final Supplier<Stream<Integer>> s = () -> Stream.iterate(0, i -> true, i -> i + 1).limit(6).flatMap(i -> Stream.of(i, i));

E então, vamos fazer a redução tosca somando! Para o primeiro sabor:

final int l1 = s.get().collect(Collectors.reducing((a, b) -> a + b)); // Valued[30]

Posso verificar também forçando um limit(0) para ver como se comporta com streams vazias:

final int l2 = s.get().limit(0).collect(Collectors.reducing((a, b) -> a + b)); // Empty[]

Acumulando com elemento neutro:

final int l3 = s.get().collect(Collectors.reducing(0, (a, b) -> a + b)); // 30

Variando o elemento neutro para obter outros valores também… (o que em tese significa que não seria o elemento neutro, né? Enfim, só para testar hipóteses mesmo…)

final int l4 = s.get().collect(Collectors.reducing(100, (a, b) -> a + b)); // 130

Sério, não façam isso de colocar um elemento não neutro! Nada fica confiável!

E, finalmente, que tal uma redução de concatenação de strings para o último sabor?

final String l5 = s.get().collect(Collectors.reducing("", a -> "" + a, (a, b) -> a + b));
// 001122334455

summing

Aqui temos 3 funções, que compartilham da mesma alma:

summingInt
summingLong
summingDouble

O summingDouble pode ter um cuidado adicional para evitar perda de precisão por ponto flutuante? Pode ter. Vou abordar isso? Não. Vou simplesmente delegar para a exata mesma forma que vou resolver os demais summing: um receptáculo para carregar os elementos somados com o tipo que está sendo usado (porém sem boxing). Vou implementar apenas o summingInt, o resto é inferência trocando int por long ou double e Integer por Long ou Double. E também adequando o tipo da função que retorna primitivo: ToIntFunction.applyAsInt vs ToLongFunction.applyAsLong vs ToDoubleFunction.applyAsDouble.

No sumário da documentação não cita, mas na descrição completa é citado que se a stream estiver vazia o retorno deve ser 0:

public static <T> Collector<T, ?, Integer> summingInt(ToIntFunction<T> mapper) {

    class Holder {
        int soma = 0;

        void acc(T t) {
            final int v = mapper.applyAsInt(t);
            soma += v;
        }

        Holder combine(Holder other) {
            soma += other.soma;
            return this;
        }

        int finish() {
            return soma;
        }
    }
    return of(
        Holder::new,
        Holder::acc,
        Holder::combine,
        Holder::finish
    );
}

Para testar, aproveitei o código do partitioningBy e somei os pares/ímpares do meu conjunto:

System.out.println(
    Stream.of(1, 2, 3, 4)
        .collect(
            Collectors.partitioningBy(
                i -> i % 2 == 0,
                Collectors.summingInt(i -> i)
            )
        )
);
// {false=4, true=6}

averaging

Tal qual o summing, tem 3 funções que compartilham a mesma alma:

averagingInt
averagingLong
averagingDouble

O código é a cópia do summing com 2 diferenças:

vou contar a quantidade de elementos (em um long)
para finalizar, vou dividir pela quantidade de elementos (exceto se vaio, aí retorna 0 mesmo)

Mesma linha de pensamento aqui que só vou apresentar o averagingInt, não vou me repetir mais do que o código abaixo ser uma verdadeira duplicação:

public static <T> Collector<T, ?, Double> averagingInt(ToIntFunction<T> mapper) {

    class Holder {
        int soma = 0;
        long contagem = 0;

        void acc(T t) {
            final int v = mapper.applyAsInt(t);
            soma += v;
            contagem++;
        }

        Holder combine(Holder other) {
            soma += other.soma;
            contagem += other.contagem;
            return this;
        }

        double finish() {
            if (contagem == 0) {
                return 0;
            }
            return ((double)soma)/contagem;
        }
    }
    return of(
        Holder::new,
        Holder::acc,
        Holder::combine,
        Holder::finish
    );
}

Mesmo teste adequando o coletor:

System.out.println(
    Stream.of(1, 2, 3, 4)
        .collect(
            Collectors.partitioningBy(
                i -> i % 2 == 0,
                Collectors.averagingInt(i -> i)
            )
        )
);
// {false=2.0, true=3.0}

summarizing

Tal qual summing, mesma alma em 3 cantos:

summarizingInt
summarizingLong
summarizingDouble

Esses coletores retornam o *SummaryStatistics adequado ao tipo. Basicamente o tipo *SummaryStatistics vai guiar a aplicação das funções summarizing, então só vou delegar pra ela. Vou usar o mapping para fazer a decoração adequada e diminuir fricção de implementação:

public static <T> Collector<T, ?, IntSummaryStatistics> summarizingInt(ToIntFunction<T> mapper) {
    return Collectors.mapping(mapper, of(
        IntSummaryStatistics::new,
        IntSummaryStatistics::accept,
        IntSummaryStatistics::combine
    ));
}

Vamos usar o IntSummaryStatistics do java inicialmente como rascunho e… Hmmm, não compilou? Ué… Ah! Claro! combiner aceita um BinaryOperator e aqui o IntSummaryStatistics::combine retorna void. Nada que um toOperator não resolva.

Mas ainda não foi, ué… Ah! mapper não é do tipo Function<T, Integer>, mas posso passar pra ele a referência do método, que então o compilador vai transformar em Function<T, Integer>:

public static <T> Collector<T, ?, IntSummaryStatistics> summarizingInt(ToIntFunction<T> mapper) {
    return Collectors.mapping(mapper::applyAsInt, of(
        IntSummaryStatistics::new,
        IntSummaryStatistics::accept,
        toOperator(IntSummaryStatistics::combine)
    ));
}

Ok, isso de lado, vamos agora implementar o IntSummaryStatistics! Aqui ele vai ter algo em comum com o averagingInt: vou precisar contar também quantos elementos foram aceitos. Mas tem algumas variações a mais:

precisa guardar o máximo e o mínimo
implementa IntConsumer
mínimo e máximo tem placeholders (vide documentação)

Como estratégia, ao aceitar um novo valor, ao faço a soma dele e aumenta a contagem, e também aproveito para verificar o max e o min. Em relação à média, bem… eu posso manter ele sempre atualizado ou então marcar o registro como sujo. É, isso parece mais barato. E quando eu pedir a média eu a calculo, registro ela no campo e marco que está limpo.

public class IntSummaryStatistics implements IntConsumer {

    private int max = Integer.MIN_VALUE;
    private int min = Integer.MAX_VALUE;
    private long count = 0;
    private long acc = 0;
    private boolean dirty = false;
    private double avg;

    @Override
    public void accept(int value) {
        dirty = true;
        acc += value;
        count++;

        if (value > max) {
            this.max = value;
        }
        if (value < min) {
            this.min = value;
        }
    }

    public void combine(IntSummaryStatistics other) {
        if (other.count == 0) {
            // não tem nada o que fazer aqui
            return;
        }

        this.dirty = true;
        this.acc += other.acc;
        this.count += other.count;

        if (other.max > this.max) {
            this.max = other.max;
        }
        if (other.min < this.min) {
            this.min = other.min;
        }
    }

    public double getAverage() {
        if (count == 0) {
            return 0.0;
        }
        if (dirty) {
            avg = ((double) acc)/count;
            dirty = false;
        }
        return avg;
    }

    public int getMax() {
        return max;
    }

    public int getMin() {
        return min;
    }

    public long getSum() {
        return acc;
    }

    public long getCount() {
        return count;
    }
}

Para teste? Que tal pegar o summarizingInt para os números de 1 a 4?

System.out.println(
    Stream.of(1, 2, 3, 4)
        .collect(
            Collectors.summarizingInt(i -> i)
        )
);

E… IntSummaryStatistics@234bef66? Ah, sim. Ele não define um toString adequado. Vamos imprimir então a média, mínima, máximo, soma e contagem:

final IntSummaryStatistics s = Stream.of(1, 2, 3, 4)
        .collect(
            Collectors.summarizingInt(i -> i)
        );
final HashMap<String, Object> valores = new HashMap<>();
valores.put("avg", s.getAverage());
valores.put("sum", s.getSum());
valores.put("max", s.getMax());
valores.put("min", s.getMin());
valores.put("cnt", s.getCount());
System.out.println(valores);

E o resultado veio conforme esperado (aqui eu dei um prettify):

{
    avg=2.5,
    min=1,
    max=4,
    cnt=4,
    sum=10
}

toMap

O toMap vem em dois sabores:

não vai ter conflito de chaves
vai ter conflito de chaves (passando uma função de merge)

Eu posso meio que mapear o sabor de que não vai ter conflito passando como função de merge uma função que estoura uma exceção ao ser chamada:

public static <T, K, V> Collector<T, ?, Map<K, V>> toMap(Function<T, K> keyExtractor,
                                                         Function<T, V> valueExtractor) {

    return toMap(keyExtractor, valueExtractor,
                 (a, b) -> {
                    throw new IllegalStateException("oops, conflito de chave");
                });
}

Ok, e como podemos lidar com o coletor para mapa? Bem, se eu tivesse acesso à API default do mapa de usar merge, tudo seria fácil. Vamos explorar essa possibilidade?

public static <T, K, V> Collector<T, ?, Map<K, V>> toMap(Function<T, K> keyExtractor,
                                                         Function<T, V> valueExtractor,
                                                         BinaryOperator<V> conflictMerge) {

    return of(
        HashMap::new,
        (m, e) -> m.merge(
            keyExtractor.apply(e),
            valueExtractor.apply(e),
            conflictMerge
        ),
        toOperator(Map::putAll)
    );
}

MAS… eu não tenho essa operação de Map.merge, então preciso simular ela na prática. Então, vamos simular esse merge?

Primeiro, eu vou precisar da chave e do valor. Vou tentar fazer o mínimo de operações de put, logo nada de fazer put e com isso obter o valor anterior que tinha ali. Pela documentação desse coletor, ele delegaria para Map.merge tal qual foi ensaiado ali. Como eu faria? Resgata o valor antigo, combina com o novo, insere. E segundo a documentação desse método, como que ele faz? Tem ordem na operação de combinar/mergear?

V oldValue = map.get(key);
V newValue = (oldValue == null) ? value : remappingFunction.apply(oldValue, value);
if (newValue == null)
    map.remove(key);
 else
    map.put(key, newValue);

Ok, não só tem como ele também remove o valor antigo. Fui atrás de saber como que era a ordem dos argumentos da operação e tenho um algoritmo pronto. E não iria diferir muito do que eu usaria:

public static <T, K, V> Collector<T, ?, Map<K, V>> toMap(Function<T, K> keyExtractor,
                                                         Function<T, V> valueExtractor,
                                                         BinaryOperator<V> conflictMerge) {

    return of(
        HashMap::new,
        (m, e) -> {
            final K key = keyExtractor.apply(e);
            final V value = valueExtractor.apply(e);
            final V oldValue = m.get(key);
            final V newValue;

            if (oldValue == null) {
                newValue = value;
            } else {
                newValue = conflictMerge.apply(oldValue, value);
            }
            m.put(key, newValue);
        },
        toOperator(Map::putAll)
    );
}

Mas… e tá certo isso? Bem, tem uma chance de que os acumuladores intermediários compartilhem uma chave, o que significa que eu deveria passar pelo conflictMerge no lugar de putAll… Ok, precisamos ajeitar esse ponto do combinador! O que significa que vou precisar fazer o mesmo processo de merge no combinador também. A função de merge recebe 4 valores:

mapa onde vai ser inserido valor
chave
novo valor a entrar (ou mesclar)
conflictMerge

Vou chamar essa função de mapMerge:

private static <K, V> void mapMerge(Map<K, V> m,
                                    K key,
                                    V value,
                                    BinaryOperator<V> conflictMerge) {
    final V oldValue = m.get(key);
    final V newValue;

    if (oldValue == null) {
        newValue = value;
    } else {
        newValue = conflictMerge.apply(oldValue, value);
    }
    m.put(key, newValue);
}

Substituindo no acumulador:

(m, e) -> {
    final K key = keyExtractor.apply(e);
    final V value = valueExtractor.apply(e);
    mapMerge(m, key, value, conflictMerge);
}

E para o combinador é ainda mais fácil: itero no mapa do lado direito e chamo para cada par o mapMerge:

(lhs, rhs) -> {
    for (final Entry<K, V> e: rhs.entrySet()) {
        final K key = e.getKey();
        final V value = e.getValue();
        mapMerge(lhs, key, value, conflictMerge);
    }
    return lhs;
}

Tudo junto ficaria assim:

private static <K, V> void mapMerge(Map<K, V> m,
                                    K key,
                                    V value,
                                    BinaryOperator<V> conflictMerge) {
    final V oldValue = m.get(key);
    final V newValue;

    if (oldValue == null) {
        newValue = value;
    } else {
        newValue = conflictMerge.apply(oldValue, value);
    }
    m.put(key, newValue);
}

public static <T, K, V> Collector<T, ?, Map<K, V>> toMap(Function<T, K> keyExtractor,
                                                         Function<T, V> valueExtractor,
                                                         BinaryOperator<V> conflictMerge) {

    return of(
        HashMap::new,
        (m, e) -> {
            final K key = keyExtractor.apply(e);
            final V value = valueExtractor.apply(e);
            mapMerge(m, key, value, conflictMerge);
        },
        (lhs, rhs) -> {
            for (final Entry<K, V> e: rhs.entrySet()) {
                final K key = e.getKey();
                final V value = e.getValue();
                mapMerge(lhs, key, value, conflictMerge);
            }
            return lhs;
        }
    );
}

APIs além do Java 8

Os gatherers serão deixados de lado, irei pegar as evoluções de Stream, de Optional e de Collectors até o Java 17 e fazer o backport.

Novidades

Stream:

mapMulti (16)
takeWhile (9)
dropWhile (9)
toList (16)
ofNullable (9)
iterate (9)
- sabor com seed, operador para próximo elemento e condicional de saber se tem próximo

O iterate já foi feito, como explicado acima, por facilidade.

Optional:

isEmpty (11)
ifPresentOrElse (9)
or (9)
stream (9)
orElseThrow (10)
- sabor vazio, lança NoSuchElementException

Collectors:

flatMapping (9)
filtering (9)
teeing (12)

Para as implementações do Optional, vou fornecer tanto para o “sabor” com subclasses como para o “sabor” em que o objeto precisa se inspecionar para saber se tem conteúdo.

Para as abordagens do Optional como subclasses, vou usar a versão com as classes nomeadas Just/None que servem o mesmo propósito do que a instanciação anônima, sem necessidade de maiores divagações.

Stream.mapMulti

Aqui recebemos um argumento: um BiConsumer, que recebe tanto um elemento que vem da stream sendo processada quanto também um Consumer para o elemento que vem a seguir.

Por exemplo, podemos usar para pegar os divisores de um número:

// Stream<Integer> s = ...
s.mapMulti((i, c) -> {
    for (int d = 1; d <= i; d++) {
        if (i % d == 0) {
            c.accept(d);
        }
    }
}).toList();

Muito bem, agora, como podemos transformar isso para as restrições que temos? Bem, isso isso mapeia um objeto do tipo T para (possivelmente) muitos objetos do tipo R. Sabe o que mais também faz isso? flatMap!

Então, como podemos transformar esse Consumer<R> que é passado para a função algo que retorne um Stream<R>? Bem, podemos passar um Stream.Builder<R>!

Então, vamos lá… vou transformar um mapMulti em uma chamada de flatMap, de algum jeito… que tal, para cada elemento recebido, criar um Stream.Builder<R> próprio e depois que terminar retornar o build dela?

public <R> Stream<R> mapMulti(BiConsumer<T, Consumer<R>> c) {
    return flatMap(t -> {
        Builder<R> b = builder();
        c.accept(t, b);
        return b.build();
    });
}

Dá para fazer de outro modo mais direto? Sim, plenamente possível. Porém transformar esse BiConsumer para mandar de modo guloso para o resto da pipeline sem terminar o processamento do elemento passado no mapMulti é uma engenharia completamente diferente do que foi feito aqui para a implementação do Stream contido aqui. Mas isso já está bom o suficiente, tal qual o momento em que fizemos uma implementação um dedo eager do filter.

Stream.takeWhile

Aqui a ideia é parar o processamento na primeira vez que o meu predicado indicar que deu ruim. Então, vamos seguir normalmente como um simples wrapper:

// TODO apenas um dummy para começar a pensar!
public Stream<T> takeWhile(Predicate<T> condition) {
    return new Stream<>(() -> new Iterator<>() {

        private final Iterator<T> innerIterator;

        {
            this.innerIterator = it.iterator();
        }

        @Override
        public boolean hasNext() {
            return innerIterator.hasNext();
        }

        @Override
        public T next() {
            return innerIterator.next();
        }
    });
}

Ok, agora eu preciso identificar se ele já encontrou uma condição ruim. Posso manter uma variável chamada goon que, antes de perguntar se tem próximo, consulta essa variável. Se pode ir adiante, segue normal. Caso contrário, já podemos parar o processamento:

// TODO apenas um dummy para começar a pensar!
public Stream<T> takeWhile(Predicate<T> condition) {
    return new Stream<>(() -> new Iterator<>() {

        private final Iterator<T> innerIterator;
        private boolean goon = true;

        {
            this.innerIterator = it.iterator();
        }

        @Override
        public boolean hasNext() {
            if (!goon) {
                return false;
            }
            return innerIterator.hasNext();
        }

        @Override
        public T next() {
            return innerIterator.next();
        }
    });
}

Agora, para eu saber se de fato tem um próximo elemento, primeiro eu preciso fazer o fetch desse elemento, e só eu posso passar para a condição. Aqui vou seguir uma estratégia semelhante a que foi usada no filter: fazer o fetch a priori e depois a cada next atualizar o elemento. E, quando se resgatar o elemento, eu já aproveito e passo na condição. Falando nisso, agora que vou fazer o fetch gulosamente, não preciso verificar no meu iterator se ele ainda tem elemento: eu já sei disso.

Então, como que fica?

public Stream<T> takeWhile(Predicate<T> condition) {
    return new Stream<>(() -> new Iterator<>() {

        private final Iterator<T> innerIterator;
        private boolean goon = true;
        private T nextElement;

        {
            this.innerIterator = it.iterator();
            magicFunction();
        }

        @Override
        public boolean hasNext() {
            return goon;
        }

        @Override
        public T next() {
            final T returnedValue = nextElement;
            magicFunction();
            return returnedValue;
        }

        private void magicFunction() {
            if (!innerIterator.hasNext()) {
                goon = false;
                return;
            }
            nextElement = innerIterator.next();
            goon = condition.test(nextElement);
        }
    });
}

Hmmm, tentei começar com algo mais distinto do filter mas acabei fazendo uma função bem dizer igualzinha, né? Com poucas diferenças: só o magicFunction mesmo que muda. Então, por que não utilizar os moldes de lá?

public Stream<T> takeWhile(Predicate<T> condition) {
    return new Stream<>(() -> new Iterator<>() {

        private final Iterator<T> innerIterator;
        private boolean _hasNext;
        private T _next;
        
        {
            this.innerIterator = it.iterator();
            magicFunction();
        }

        @Override
        public boolean hasNext() {
            return _hasNext;
        }

        @Override
        public T next() {
            final T returnedValue = _next;
            magicFunction();
            return returnedValue;
        }

        private void magicFunction() {
            if (!innerIterator.hasNext()) {
                _hasNext = false;
                return;
            }
            _next = innerIterator.next();
            _hasNext = condition.test(_next);
        }
    });
}

Stream.dropWhile

Aqui a ideia é começar com o primeiro elemento na moda do filter, mas pro elemento seguinte seria só um wrapper comum em cima do iterador. Então, será que agora dá certo começar com o wrapper e terminar com boa parte intacta dele?

// TODO apenas um dummy para começar a pensar!
public Stream<T> dropWhile(Predicate<T> dropCondition) {
    return new Stream<>(() -> new Iterator<>() {

        private final Iterator<T> innerIterator;

        {
            this.innerIterator = it.iterator();
        }

        @Override
        public boolean hasNext() {
            return innerIterator.hasNext();
        }

        @Override
        public T next() {
            return innerIterator.next();
        }
    });
}

Eu preciso fazer um comportamento especial apenas na primeira chamada. Então vou criar aqui um fluxo especial só pra isso. E preciso identificar separadamente para hasNext e para next, de modo que a primeira chamada do hasNext ache apenas uma vez o primeiro elemento:

// TODO apenas um dummy para começar a pensar!
public Stream<T> dropWhile(Predicate<T> dropCondition) {
    return new Stream<>(() -> new Iterator<>() {

        private final Iterator<T> innerIterator;
        private boolean beforeFirst = true;
        private boolean beforeFirstNext = true;
        private boolean foundFirstElement;
        private T firstElement;

        {
            this.innerIterator = it.iterator();
        }

        @Override
        public boolean hasNext() {
            if (beforeFirst) {
                beforeFirst = false; // garante que só faz uma vez
                _dropWhile();
                return foundFirstElement;
            } else if (beforeFirstNext) {
                return foundFirstElement;
            }
            return innerIterator.hasNext();
        }

        @Override
        public T next() {
            if (beforeFirstNext) {
                beforeFirstNext = false;
                return firstElement;
            }
            return innerIterator.next();
        }

        private void _dropWhile() {
            // TODO fazer aqui os efeitos colaterais adequados
            // preencher `foundFirstElement` e `firstElement`
        }
    });
}

Ok, agora… algumas coisinhas para se levar em consideração… o comportamento parece por cima adequado para se usar via iteração tradicional do Java (não com chamadas manuais, mas enfim, no geral no caso de uso sim, até porque não tenho esse iterador exposto). Mas… o firstElement fica preso. Isso é ruim. Então, após achar o valor, podemos limpar a memória: não tenho porque ficar com isso preso sem deixar ser coletado!

@Override
public T next() {
    if (beforeFirstNext) {
        final T el = firstElement;
        firstElement = null;
        beforeFirstNext = false;
        return el;
    }
    return innerIterator.next();
}

Pronto, agora só implementar _dropWhile()… Mas, sinceramente, essa é fácil! Loopar no iterador até encontrar algo que não satisfaça o filtro: achou isso, marcamos que achou o primeiro elemento e povoamos ele:

private void _dropWhile() {
    while (innerIterator.hasNext()) { // claro que só podemos loopar enquanto há elementos!
        final T t = innerIterator.next();
        if (!dropCondition.test(t)) {
            // não é mais condição de dropar, agora abortamos com algo
            foundFirstElement = true;
            firstElement = t;
            return;
        }
    }
    foundFirstElement = false;
}

Na visão geral fica assim:

public Stream<T> dropWhile(Predicate<T> dropCondition) {
    return new Stream<>(() -> new Iterator<>() {

        private final Iterator<T> innerIterator;
        private boolean beforeFirst = true;
        private boolean beforeFirstNext = true;
        private boolean foundFirstElement;
        private T firstElement;

        {
            this.innerIterator = it.iterator();
        }

        @Override
        public boolean hasNext() {
            if (beforeFirst) {
                beforeFirst = false; // garante que só faz uma vez
                _dropWhile();
                return foundFirstElement;
            } else if (beforeFirstNext) {
                return foundFirstElement;
            }
            return innerIterator.hasNext();
        }

        @Override
        public T next() {
            if (beforeFirstNext) {
                final T el = firstElement;
                firstElement = null;
                beforeFirstNext = false;
                return el;
            }
            return innerIterator.next();
        }

        private void _dropWhile() {
            while (innerIterator.hasNext()) { // claro que só podemos loopar enquanto há elementos!
                final T t = innerIterator.next();
                if (!dropCondition.test(t)) {
                    // não é mais condição de dropar, agora abortamos com algo
                    foundFirstElement = true;
                    firstElement = t;
                    return;
                }
            }
            foundFirstElement = false;
        }
    });
}

Ficou mais conturbado do que eu tinha pensado a primeira vista. Mas manteve por alto a aparência do wrapper do iterator.

Stream.toList

Aqui a saída mais covarde é simplesmente chamar o coletor de lista:

public List<T> toList() {
    return collect(Collectors.toList());
}

Porém podemos fazer isso de modo mais interessante, né? Já que o stream no final das contas tem um iterator, posso adicionar todos os elementos desse iterador na minha própria lista:

public List<T> toList() {
    final ArrayList<T> c = new ArrayList<>();

    for (final T t: it) {
        c.add(t);
    }
    return c;
}

Stream.ofNullable

O ofNullable retorna uma stream de um elemento caso ele seja não nulo, ou vazio caso ele seja:

public static <T> Stream<T> ofNullable(T t) {
    return t == null? empty(): of(t);
}

Optional.isEmpty

Basicamente posso sempre implementar como o contrário do isPresent:

public boolean isEmpty() {
    return !isPresent();
}

Como isso vai sofrer (muito possivelmente) inlining pelo JIT, tanto faz. Mas podemos também fazer a versão direta! Para o caso em que precisa inspecionar o valor:

public boolean isEmpty() {
    return v == null;
}

Com subclasses:

private static class Just<T> extends Optional<T> {
    // ...

    @Override
    public boolean isEmpty() {
        return false;
    }
}

private static class None<T> extends Optional<T> {
    // ...

    @Override
    public boolean isEmpty() {
        return true;
    }
}

Optional.ifPresentOrElse

Aqui é uma adaptação direta do ifPresent. Para o caso em que precisa inspecionar o próprio estado:

public void ifPresentOrElse(Consumer<T> c, Runnable r) {
    if (v != null) {
        c.accept(v);
    } else {
        r.run();
    }
}

Para subclasses:

private static class Just<T> extends Optional<T> {
    // ...

    @Override
    public void ifPresentOrElse(Consumer<T> c, Runnable r) {
        c.accept(v);
    }
}

private static class None<T> extends Optional<T> {
    // ...

    @Override
    public void ifPresentOrElse(Consumer<T> c, Runnable r) {
        r.run();
    }
}

Optional.or

Aqui a intenção é: se meu Optional estiver vazio, eu executo a função passada e assim obtenho um novo Optional de mesmo tipo.

Para a versão que precisa verificar o estado interno:

public Optional<T> or(Supplier<Optional<T>> supplier) {
    return v == null? supplier.get(): this;
}

Para o caso de subclasses, nada demais: o vazio chama o supplier, o que tem valor simplesmente se retorna:

private static class Just<T> extends Optional<T> {
    // ...

    @Override
    public Optional<T> or(Supplier<Optional<T>> supplier) {
        return this;
    }
}

private static class None<T> extends Optional<T> {
    // ...

    @Override
    public Optional<T> or(Supplier<Optional<T>> supplier) {
        return supplier.get();
    }
}

Optional.stream

Para o caso em que precisa olhar pra si mesmo: se for vazio, retorna Stream.empty(). Caso contrário, retorna o próprio elemento em uma stream unitária:

public Stream<T> stream() {
    return v == null? Stream.empty(): Stream.of(v);
}

Ou então usando o Stream.ofNullable:

public Stream<T> stream() {
    return Stream.ofNullable(v);
}

Para subclasses, o None retorna simplesmente que é empty e o Just retorna Stream.of:

private static class Just<T> extends Optional<T> {
    // ...

    @Override
    public Stream<T> stream() {
        return Stream.of(v);
    }
}

private static class None<T> extends Optional<T> {
    // ...

    @Override
    public Stream<T> stream() {
        return Stream.empty();
    }
}

Optional.orElseThrow

Aqui eu simplesmente delego para o orElseThrow existente, chamando o Supplier de exceção adequado:

public T orElseThrow() {
    return orElseThrow(() -> new NoSuchElementException("Optional is empty!"));
}

Isso para o caso em que eu defino tanto para o Optional que olha o seu estado quanto possivelmente para saber se é vazio como para o None. Para o caso do Optional via subclasses com valor, o orElseThrow simplesmente retorna o seu próprio valor interno, tal qual o outro sabor do orElseThrow:

private static class Just<T> extends Optional<T> {
    // ... implementação anterior ...

    // mantendo a referência só para ficar mais fácil consultar
    @Override
    public <E extends Exception> T orElseThrow(Supplier<E> s) throws E {
        return v;
    }

    @Override
    public T orElseThrow() {
        return v;
    }
}

Outra alternativa do None seria simplesmente lançar a exceção:

private static class None<T> extends Optional<T> {
    // ...
    public T orElseThrow() {
        throw new NoSuchElementException("Optional is empty!");
    }
}

Collectors.flatMapping

A ideia do flatMapping é aplainar elementos em forma de stream antes de passar esses elementos para o coletor final. Só que com esse cuidado segundo a documentação:

If a mapped stream is null an empty stream is used, instead.

Ou seja, se mapear pra nulo, retornar uma stream vazia no lugar. Ok, como podemos fazer isso? Vamos usar como intermediário o que é gerado pelo downstream. Na hora de receber um elemento do tipo T (que vem da minha stream nativa, digamos assim), eu não o jogo diretamente para o acumulador, porém eu pego o stream gerado e consumo todos os elementos dele no acumulador. Hmmm, é, na prática se eu receber nulo eu posso simplesmente abortar a computação, né?

public static <T, U, A, V> Collector<T, ?, V> flatMapping(Function<T, Stream<U>> mapper, Collector<U, A, V> downstream) {
    final BiConsumer<A, U> baseAcc = downstream.accumulator();
    return of(
        downstream.supplier(),
        (m, t) -> {
            final Stream<U> flattened = mapper.apply(t);
            if (flattened == null) {
                return;
            }
            flattened.forEach(u -> baseAcc.accept(m, u));
        },
        downstream.combiner(),
        downstream.finisher()
    );
}

Bem, aparentemente é só isso, sem maiores complicações.

Collectors.filtering

Aqui a ideia é passar apenas alguns dos argumentos para o acumulador. Bem direto:

public static <T, A, V> Collector<T, ?, V> filtering(Predicate<T> filter, Collector<T, A, V> downstream) {
    final BiConsumer<A, T> baseAcc = downstream.accumulator();
    return of(
        downstream.supplier(),
        (m, t) -> {
            if (filter.test(t)) {
                baseAcc.accept(m, t);
            }
        },
        downstream.combiner(),
        downstream.finisher()
    );
}

Collectors.teeing

Aqui vamos fazer bem dizer a operação tee: pegar um input e direcionar para dois outputs. A diferença apenas é que depois de obter dois resultados, iremos combinar os dois resultados no final: ou seja, o finisher é aplicar os finishers de cada coletor e depois aplicar a função específica de combinação de resultados.

O meu maior mistério é entender porque o pessoal do Java não quis explicitar os tipos intermediários dos dois coletores, isso na minha visão atrapalha a codificação do teeing, mas tudo bem, vamos abstrair isso! Como? Chamando uma função que tenha essas genéricos:

public static <T, R1, R2,R> Collector<T,?,R> teeing(Collector<T, ?, R1> downstream1,
                                                    Collector<T, ?, R2> downstream2,
                                                    BiFunction<R1, R2, R> merger) {
    return _teeing(downstream1, downstream2, merger);
}

private static <T, A1, A2, R1, R2, R> Collector<T,?,R> _teeing(Collector<T, A1, R1> downstream1,
                                                Collector<T, A2, R2> downstream2,
                                                BiFunction<R1, R2, R> merger) {
    // TODO completar
    return ...;
}

Ok, vamos manter os valores intermediários? Vou precisar de um Holder local aqui por conta dos dois acumuladores intermediários. Esse Holder vai ser bem monótono: só delegar às funções dos downstreams. Só o finisher que é quase mais interessante, porque vai precisar passar para o merger. Mas só isso, nada de mais:

private static <T, A1, A2, R1, R2, R> Collector<T,?,R> _teeing(Collector<T, A1, R1> downstream1,
                                                Collector<T, A2, R2> downstream2,
                                                BiFunction<R1, R2, R> merger) {

    final BiConsumer<A1, T> acc1 = downstream1.accumulator();
    final BiConsumer<A2, T> acc2 = downstream2.accumulator();
    
    final BinaryOperator<A1> comb1 = downstream1.combiner();
    final BinaryOperator<A2> comb2 = downstream2.combiner();
    
    final Supplier<A1> sup1 = downstream1.supplier();
    final Supplier<A2> sup2 = downstream2.supplier();

    class Holder {
        A1 a1;
        A2 a2;
        
        Holder() {
            a1 = sup1.get();
            a2 = sup2.get();
        }

        void acc(T t) {
            acc1.accept(a1, t);
            acc2.accept(a2, t);
        }
        
        Holder comb(Holder other) {
            a1 = comb1.apply(a1, other.a1);
            a2 = comb2.apply(a2, other.a2);
            return this;
        }
        
        R finisher() {
            final R1 r1 = downstream1.finisher().apply(a1);
            final R2 r2 = downstream2.finisher().apply(a2);
            
            return merger.apply(r1, r2);
        }
    }
    return of(
        Holder::new,
        Holder::acc,
        Holder::comb,
        Holder::finisher
    );
}

Os valores intermediários guardados são apenas para não ficar chamando diversas vezes downstream.accumulator() ou outros dos métodos do coletor.

O conjunto que contém todos os conjuntos que se contém contém a si? Ou como side effects são infernais

Thu, 16 Apr 2026 00:00:00 +0000

Se eu tiver um conjunto, que contém a todos os conjuntos que contém a si mesmos, ele deveria conter a si mesmo?

Bem, podemos tentar explorar isso de algumas formas, como por exemplo tentar encontrar alguma contradição ao tentar construir esse conjunto. Vamos dizer que ele não poderia estar dentro de si, então vamos supor que ele está dentro de si mesmo e torcer para encontrar uma contradição…

Então, bora lá…

$C \in C$

Dado isso, obtemos alguma contradição? Hmmm, não. O conjunto tá dentro dele, então tudo se comporta de modo esperado. Portanto, o correto seria que o conjunto não se contivesse, não é mesmo?

$C \not\in C$

Bem, se ele não se contém, não tenho nenhuma contradição também…

Ou seja, eu não consigo encontrar uma contradição e de toda sorte eu conseguiria construir esse conjunto, tanto contendo a si mesmo como não contendo a si mesmo.

Estranho, né?

Familiar?

Note que aqui não estou lidando com o paradoxo clássico de Russell, mas o complemento dele. O paradoxo de Russell é descrito de outra maneira:

O conjunto com todos os conjuntos que não contém a si mesmos, deveria se estar dentro dele mesmo?

$C = \left\{ x | x \not\in x \right\}$

Já esse que eu introduzi é determinado sem essa negação:

$C = \left\{ x | x \in x \right\}$

Enquanto o paradoxo de Russell é por definição uma contradição, o que foi descrito acima na real é uma indefinição.

E o que isso tem a ver com programação?

Bem, vamos lá. Imagina o seguinte pseudo-código:

let a = 0;

function b() {
    global a;
    a += 100;
    return 0;
}

a += b();
console.log(a);

Qual o valor que a vai assumir? Pois aqui temos o problema, os efeitos colaterais de a fazem parte da a sendo somado?

Stack machines

Vamos pegar um exemplo em Java:

int a = 0;

int b() {
    a += 100000;
    return 0;
}

void main(String[] args) {
    a += b();
    IO.println(a);
}

Isso imprime 0. “Mas por quê?” você pode estar se perguntando. Bem, vamos ver como que o Java resolveu os bytecodes:

  void main(java.lang.String[]);
         0: aload_0
         1: dup
         2: getfield      #7                  // Field a:I
         5: aload_0
         6: invokevirtual #14                 // Method b:()I
         9: iadd
        10: putfield      #7                  // Field a:I
        13: aload_0
        14: getfield      #7                  // Field a:I
        17: invokestatic  #18                 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
        20: invokestatic  #24                 // Method java/lang/IO.println:(Ljava/lang/Object;)V
        23: return

A operação a += ... é realizada da seguinte maneira:

aload_0 carrega o objeto this
dup agora tem esse objeto duas vezes na pilha
getfield carrega o campo a (remove uma das cópias do this da pilha)
alguma coisa pra calcular o lado direito (RHS, right hand side)
iadd, somando os dois elementos da pilha (o a carregado anteriormente e o resultado do RHS)
putfield que vai inserir o elemento da pilha no lugar de a (consumindo o this que foi duplicado na segunda operação)

Tá, talvez aqui tenhamos alguma quirk porque estou usando classe anônima e instance main. E se fosse tudo static?

class Example {
    static int a = 0;

    static int b() {
        a += 100000;
        return 0;
    }

    public static void main(String[] args) {
        a += b();
        IO.println(a);
    }
}

O bytecode gerado foi esse:

 public static void main(java.lang.String[]);
         0: getstatic     #7                  // Field a:I
         3: invokestatic  #14                 // Method b:()I
         6: iadd
         7: putstatic     #7                  // Field a:I
        10: getstatic     #7                  // Field a:I
        13: invokestatic  #18                 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
        16: invokestatic  #24                 // Method java/lang/IO.println:(Ljava/lang/Object;)V
        19: return

A parte do a += ... é basicamente a mesma coisa, mas usando getstatic/putstatic no lugar de referência ao objeto this:

getstatic pega o valor de a
resolve o RHS
iadd soma os valores da pilha (o valor antigo de a e o RHS)
putstatic insere o valor calculado no iadd de volta na variável a

Então, aqui, o valor de a que vai ser somado, inclui os efeitos colaterais? Não. Mas isso aqui tem um comportamento diferente:

int a = 0;

int b() {
    a += 100000;
    return 0;
}

void main(String[] args) {
    a = b() + a;
    IO.println(a);
}

Que gera o bytecode

         0: aload_0
         1: aload_0
         2: invokevirtual #14                 // Method b:()I
         5: aload_0
         6: getfield      #7                  // Field a:I
         9: iadd
        10: putfield      #7                  // Field a:I
        13: aload_0
        14: getfield      #7                  // Field a:I
        17: invokestatic  #18                 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
        20: invokestatic  #24                 // Method java/lang/IO.println:(Ljava/lang/Object;)V
        23: return

Note que agora primeiro se calcula b() e só depois se carrega o valor de a. Além disso, a ordem dos operandos foi alterada, porque agora o a tá do lado direito da soma, não do lado esquerdo. Isso não deveria gerar nenhum problema com nenhum tipo de número, mas vale a pena ficar atento, né?

Outra coisa que tem valor distinto:

int a = 0;

int b() {
    a += 100000;
    return 0;
}

void main(String[] args) {
    final var r = b();
    a += r;
    IO.println(a);
}

Com o bytecode

         0: aload_0
         1: invokevirtual #14                 // Method b:()I
         4: istore_2
         5: aload_0
         6: dup
         7: getfield      #7                  // Field a:I
        10: iload_2
        11: iadd
        12: putfield      #7                  // Field a:I

Aqui o valor de b() é armazenado na stack (istore_2) e depois é resgatado para ser computado (iload_2). Isso garante que o que foi computado em b() tenha ocorrido antes de carregar o valor de a para fazer a soma.

Aqui, na interpretação do Java (e não só do Java, mas de diversas linguagens), o conjunto que contém as mudanças realizadas na variável não contém os efeitos colaterais após a descrição do operador +=. Alguns ambientes em que isso foi reproduzido:

CommonJS (Spider Monkey)
Node.JS (v8)

let a = 0
 
function b() {
 a += 100
 return 0
}
 
a += b() // vale 0

Python 3

a = 0
def b():
    global a
    a += 100
    return 0

a += b() # vale 0

Ruby

$a = 0
def b()
  $a += 100
  0
end
$a += b() # vale 0

Register machines

Vamos tentar reescrever a essência do código problemático em… C?

// só para poder imprimir o valor mesmo
#include<stdio.h>

static int a = 0;

static int b() {
    a += 100;
    return 0;
}

int main(int argc, char **argv) {
    a += b();
    printf("%d\n", a);
    return 0;
}

Vamos gerar o ASM disso em ARM (similar a o que foi feito em Otimização de função de cauda em uma toy function) para ter uma pequena base de comparação:

b:
        push    {r11, lr}
        mov     r11, sp
        ldr     r1, .LCPI0_0
.LPC0_0:
        add     r1, pc, r1
        ldr     r0, .LCPI0_1
.LPC0_1:
        ldr     r0, [pc, r0]
        add     r0, r0, #100
        str     r0, [r1]
        mov     r0, #0
        pop     {r11, lr}
        bx      lr
.LCPI0_0:
        .long   a-(.LPC0_0+8)
.LCPI0_1:
        .long   a-(.LPC0_1+8)

main:
        push    {r11, lr}
        mov     r11, sp
        sub     sp, sp, #16
        mov     r2, #0
        str     r2, [sp]
        str     r2, [r11, #-4]
        str     r0, [sp, #8]
        str     r1, [sp, #4]
        bl      b
        mov     r2, r0
        ldr     r1, .LCPI1_0
.LPC1_0:
        add     r1, pc, r1
        ldr     r0, .LCPI1_1
.LPC1_1:
        ldr     r0, [pc, r0]
        add     r0, r0, r2
        str     r0, [r1]
        ldr     r1, .LCPI1_2
.LPC1_2:
        ldr     r1, [pc, r1]
        ldr     r0, .LCPI1_3
.LPC1_3:
        add     r0, pc, r0
        bl      printf
        ldr     r0, [sp]
        mov     sp, r11
        pop     {r11, lr}
        bx      lr
.LCPI1_0:
        .long   a-(.LPC1_0+8)
.LCPI1_1:
        .long   a-(.LPC1_1+8)
.LCPI1_2:
        .long   a-(.LPC1_2+8)
.LCPI1_3:
        .long   .L.str-(.LPC1_3+8)

.L.str:
        .asciz  "%d\n"

E aqui o valor impresso é 100, não 0! Mas, por quê?

Primeiramente, gostaria de dizer que estou usando CLang 22.1.0 com target para armv7-a 32bits pelo Compiler Explorer! Recomendo testar a ferramenta, é fantástica: https://godbolt.org/.

Ah, o nome do cara é Godbolt mesmo, vide GitHub @mattgodbolt.

Bem, vejamos aqui o que acontece na parte exata a += b():

        bl      b
        mov     r2, r0
        ldr     r1, .LCPI1_0
.LPC1_0:
        add     r1, pc, r1
        ldr     r0, .LCPI1_1
.LPC1_1:
        ldr     r0, [pc, r0]
        add     r0, r0, r2
        str     r0, [r1]

Aqui:

chama a função b
guarda em r2 o que está em r0
resgata em r0 o valor de a
soma r0 com r2 e guarda o resultado em r0
guarda r0 na memória no exato lugar de a

O r1 ali em cima guarda o endereço da variável a, por isso que guardar o valor é str r0, [r1], envolvendo o r1.

Tá, mas onde tá o retorno da chamada a b()? Bem, por convenção, está em r0. E é exatamente por isso que o compilador colocou mov r2, r0, assim guardando o valor do retorno para posterior análise.

Voltando para a indefinição

Ao fazer uma computação do sentido a += RHS, precisamos somar com a o que está no lado direito. Agora, em relação a essa linha, quem é a de modo exato? Podemos dizer aqui que o valor de a é tudo aquilo que aconteceu que afetou o valor de a?

Se isso for verdade, o que acontece quando há uma auto-referência? Nesse caso a auto-referência é o RHS sendo uma função que tem efeitos colaterais em a. Aqui nesse caso temos exatamente o complemento da indefinição de Russell: ambas as respostas são satisfatórias!

No caso da linguagem Java, devido a questões de filosofia de reprodutibilidade e outras coisas mais, foi dito que o valor de a a ser carregado não iria levar em consideração o que viria no RHS. Portanto, o conjunto com todas as operações em a que antecedem a soma não inclui o RHS da função.

Para Java em específico, no Java 25, temos aqui a especificação da linguagem na seção 15.26.2, sobre operação de atribuição composta. Em primeiro lugar, se resolve o lado esquerdo, mantendo na pilha, para depois se analisar o lado direito. Após obter os dois valores, se aplica a soma e só depois que se pode guardar o valor.

Isso permite fazer isso na pilha:

0: getstatic     #7                  // Field a:I
3: invokestatic  #14                 // Method b:()I
6: iadd
7: putstatic     #7                  // Field a:I

Agora, como seria a manipulação da pilha se isso não fosse verdade? Bem, aqui a situação seria bem… não convencional… Porque, se eu quiser avaliar a função primeiro, onde que eu a guardo? Se eu fizer isso:

invokestatic  #14                 // Method b:()I
getstatic     #7                  // Field a:I
iadd
putstatic     #7                  // Field a:I

Aqui eu faço com que o retorno de b() esteja no lado esquerdo da soma, o que não queremos. E se eu fizesse um swap?

invokestatic  #14                 // Method b:()I
getstatic     #7                  // Field a:I
swap
iadd
putstatic     #7                  // Field a:I

Bem, aqui eu mantive a ordem dos elementos na hora da soma. Outras soluções para esse problema existem, mas envolvem escrita na memória, não só a questão de manipulação de coisas de um lado pro outro.

O que é o operador de atribuição composto?

Bem, vamos pensar aqui, como questão de design de linguagem: o que é essa atribuição composta do +=? Eu posso dizer que ela é sempre igual a a = a + b?

Bem, vamos lá. A operação += quer dizer “somar ao valor da esquerda o que é computado do lado direito”. Para saber o “valor da esquerda”, precisamos traçar tudo aquilo que aconteceu até aquele momento. Aqui vem a questão: vamos resolver isso de modo eager (buscar primeiro o valor) ou de modo lazy (deixar para buscar no derradeiro momento)?

Bem, isso acaba por ser uma decisão de design. No caso de implementações em C, pelo que me lembro ou é unspecified behaviour ou é undefined behaviour, (o clássico UB). Inclusive, devido a essa questão, a ordem de resolução de valores pode gerar como efeito que essas duas expressões, que deveriam significar a mesma coisa, tenham comportamentos distintos:

a += b()
a = a + b()

Isso porque: com a + b(), se eu primeiro resolver o lado esquerdo, o valor de a ainda não terá tido o efeito colateral da chamada b(). Se o compilador resolver que é melhor em uma situação resolver primeiro o lado esquerdo e depois o direito, e em outra situação fazer o contrário, ainda está tudo bem de acordo com os padrões da linguagem.

Outro ponto interessante para se levar em consideração é esse excerto, retirado da Wikipedia em inglês no artigo sobre unspecified behaviour:

a = f(b) + g(b);

O valor de a vai depender de como b vai ser resolvido. Por exemplo, se por um acaso o compilador vai pegar uma cópia de b, enviar para a função f e mandar computar g com outra cópia de b já resgatada, ele vai obter um comportamento. Agora, se por acaso ele pegar b, enviar para f, e só depois que f retornar ele pegar uma cópia de b para mandar para g, aqui podemos ter um problema: qual o valor de b? Porque agora podemos ter que f gere um efeito colateral em b. E a mesma coisa para resolver primeiro g(b) e depois resolver f(b): se g gerar efeito colateral em b, então o valor da chamada de f será distinto.

E tudo isso só acontece por conta de uma coisa que essas linguagens permitem: mutação dos dados. Agora, não estou falando em simplesmente shallow mutation, mas sim de deep mutation. Situações semelhantes poderiam acontecer se o valor de b não fosse alterado diretamente, mas qualquer valor que eu chegue por intermédio de b. Por exemplo, se eu tiver um objeto em Java que chamar a função cause alterações em seus campos mais internos, encadear essas chamadas tem um potencial caso de confusão. Em C, eu posso pegar exemplos semelhantes onde b é um ponteiro para um valor complexo, então alterações no que é apontado por b também gerar problemas semelhantes.

No fundo, para saber o valor de uma variável em determinado momento, você precisa fazer uma operação de conjunto, de pegar todas as operações que mexem naquele valor. Então, se eu preciso pegar todas as operações que alteram o valor da variável, em operações que dependem do valor da variável e que ao mesmo tempo alteram seu valor, essas operações estão dentro ou fora do conjunto?

Como resolver isso?

Uma alternativa para resolver isso é ser caxias tal qual o Java fez, e que acredito que a maioria das linguagens segue: canonizar um tipo de resposta. Agora, sabe uma solução ainda mais elegante do que isso? E é bem simples: evitar efeitos colaterais.

Toda essa discussão só se deu por conta de que o valor referenciado é alterado no meio da execução. Se não tivesse efeito colateral, essa discussão toda não estaria ocorrendo.

Esse é o preço que um sistema computacional que permite side effects oferece. Você vai precisar escolher se o conjunto que contém a todos os conjuntos contém a si mesmo ou não.

Contando pares no intervalo [a,b]

Wed, 25 Mar 2026 00:00:00 +0000

Baseado nesta minha publicação no Stack Overflow em Português

Preciso contar quantos números pares existem em um intervalo fechado de números. Missão parece bem tranquila, não é?

int conta_pares(int a, int b) {
    int i;
    int acc = 0;
    for (i = a; i <= b; i++) {
        if (i % 2 == 0) {
            acc++;
        }
    }

    return acc;
}

Mas isso pode ser melhorado, não é? Para que se sujeitar a iterar na coleção inteira? Bem, podemos contar quantos pares tem no intervalo aberto (0, a), quanto tem no intervalo fechado (0, b] e então remover os pares do intervalo (0, a). A diferença de conjuntos vai ser [a, b], conforme o esperado.

No caso, para contar a quantidade de números pares entre (0, x], basicamente é a metade de x, arredondado para baixo. Por exemplo, até 10? Temos 5 pares: 2, 4, 6, 8, 10. Até 9? Só quatro pares: 2, 4, 6, 8. Então, para computar a quantidade de pares no intervalo (0, b], já temos a fórmula.

Mas e para (0, a)? Agora o intervalo é aberto… Bem, como é aberto nos números inteiro, podemos trocar por um fechado no inteiro logo menor: (0, a-1]. Isso só vale porque estamos trabalhando com números inteiros, se fosse nos reais ou mesmo nos racionais isso já não valeria. Então, para achar os números entre [a, b]:

int conta_pares(int a, int b) {
    return b/2 - (a-1)/2;
}

Por via das dúvidas, podemos nos resguardar porque a entrada vai ser de um usuário:

int conta_pares(int a, int b) {
    if (a > b) {
        return 0;
    }
    return b/2 - (a-1)/2;
}

Muito bem, agora vamos ver a questão de novo…

só aceita recursivo…

Construção recursiva básica

Bem, voltamos aqui ao clássico problema de como expressar de modo recursivo uma solução. Então, que tal fazer assim:

começamos no intervalo [a, b]
resolvo para [a+1, b]
se a for par, adiciono 1 ao resultado do problema menor

Mas… qual seria o caso base? Bem, com um intervalo inválido! Quando a > b. E nesse caso, qual seria a solução? Seria 0 mesmo, não tem número algum nesse intervalo, muito menos pares:

int conta_pares(int a, int b) {
    if (a > b) {
        return 0;
    }
    int problema_menor = conta_pares(a + 1, b);
    return problema_menor + (a % 2 == 0? 1: 0);
}

De modo mais conciso?

int conta_pares(int a, int b) {
    if (a > b) {
        return 0;
    }

    return conta_pares(a + 1, b) + (a % 2 == 0? 1: 0);
}

Isso resolve o problema da recursão. Mas, vamos botar o chapéu da otimização da função de cauda? Tal qual em Otimização de função de cauda em uma toy function.

A estratégia que vou passar é passar adiante a solução acumulada até o momento. Como estamos em C, eu também não quero expor minhas funções para o mundo externo, quero que elas fiquem retidas na unidade de compilação: que façamos elas serem static! O static na função garante que ela não será usada para fazer linking com outros arquivos. É como se a função só existisse dentro do arquivo e fosse invisível acessar de fora:

static int _conta_pares(int a, int b, int acc) {
    // placeholder
    return 0;
}

int conta_pares(int a, int b) {
    return _conta_pares(a, b, 0);
}

Ok, vamos pensar aqui. O passo recursivo vai continuar sendo chamar apra o número seguinte da parte inferior do intervalo: [a,b] tem como subproblema o intervalo [a+1, b]. O caso base também seria o mesmo, retorno o que foi computado até o momento:

static int _conta_pares(int a, int b, int acc) {
    if (a > b) {
        return acc;
    }
    return _conta_pares(a+1, b, 0 /* placeholder esse 0 aqui! */);
}

int conta_pares(int a, int b) {
    return _conta_pares(a, b, 0);
}

Muito bem… agora, o que eu venho acumulando? A quantidade de pares! E essa grandeza nunca diminui. Portanto, vai ser acc com alguma coisa. E que coisa seria essa? Se a for par:

static int _conta_pares(int a, int b, int acc) {
    if (a > b) {
        return acc;
    }
    return _conta_pares(a+1, b, acc + (a % 2 == 0? 1: 0));
}

int conta_pares(int a, int b) {
    return _conta_pares(a, b, 0);
}

Funções de alta ordem!

Hmmm, ainda tem algo me incomodando. Eu posso transformar isso não em um conjunto de ifs, deve ter um jeito de contar automaticamente na estrutura! E, bem, temos sim! Basicamente vamos contar quantas vezes passamos pelo estado “a é par” até esgotar o limite inferior do intervalo. E esse grafo só tem dois estados: o anterior descrito e o estado “a é ímpar”, que não serve de nada.

Modelando cada estado como se fosse uma função, temos um problema: temos duas funções mutuamente recursivas. E como que podemos permitir isso em C? Usando cálculo λ e passando as funções como argumentos? Bem, até que é uma solução um tanto quanto… rebuscada… mas não precisamos disso. Mas não precisar não quer dizer não ter!

Então vamos lá! Vamos resolver do jeito difícil, depois vamos resolver do jeito mais adequado!

Nesse caso, é bom definir um tipo de função. Normalmente, para definir um tipo novo com nome simples usamos typedef. Para definir um ponto, por exemplo, podemos escrever assim:

typedef struct { int x; int y; } Ponto;

Aqui eu estou criando uma struct anônima que tem os campos x e y, e ambos esses campos são do tipo int. Então, após criar esse struct anônima eu atribuo a ela o nome Ponto. Para iniciar um valor, podemos fazer a inicialização inline:

Ponto p = {
    .x = 2,
    .y = 1
};

Que também podemos escrever de modo mais conciso:

Ponto p = { .x = 1, .y = 2 };

Podemos fazer reatribuição completa do valor também, mas para isso precisamos apresentar à struct que estamos criando o tipo dela (o compilador não infere o tipo):

Ponto p = { .x = 1, .y = 2 };
p = (Ponto) { .x = 5, .y = 0 };

E tem uma coisa bem legal também: podemos declarar campos dessa struct como const! E isso impede algumas operações ilegais:

typedef struct { const int x; const int y; } Ponto;

Ponto p = { .x = 1, .y = 2 };

p.x = 5;
// error: cannot assign to non-static data member 'x' with const-qualified type 'const int'

p = (Ponto) { .x = 5, .y = 4};
// error: cannot assign to variable 'p' with const-qualified data member 'x'

Ah, sim, tal qual Java assumimos que um campo final não pode ter seu valor alterado em tempo de execução, aqui podemos ter esse pressuposto mas com um cuidado a mais: é mais fácil em C fazer acesso ilegal a esses campos do que em Java fazer deep-reflection e mudar o campo para não ser mais final. Isso é um salva-guarda entre você e o compilador, não quer dizer que quem receba esses dados vai respeitar o acesso de memória.

Faz parte da API saudável essa declaração de tipos.

Mas para o caso de tipos de função, a coisa é um pouco mais diferente. Ao declarar o tipo de função, o nome do tipo vai entre parênteses, assim:

typedef int (*Pega_dois_int)(int a, int b);

int add(int a, int b) {
    return a + b;
}

int mult(int a, int b) {
    return a * b;
}

Pega_dois_int op = (choice == '+'? add: mult);

int v = op(first, second);
printf("%d\n", v);

O tipo Pega_dois_int foi declarado como sendo um ponteiro de função que retorna um inteir int (*)( ). E também coloquei que ele recebe dois argumentos inteiros: int (*)(int, int). O nome do tipo da função fica ali, dentro do parênteses que segura o indicador de ponteiro *.

E, bem, aqui eu não consigo me dar ao luxo de passar um tipo parcialmente conhecido como seria comum fazer com listas ligadas:

typedef struct lista {
    int value;
    struct lista *next;
} Lista;

Aqui estou construindo primeiro a struct nomeada struct lista. Essa estrutura ainda não está completamente definida, então não posso listar ela diretamente dentro de si mesma. Mas tenho indicações suficientes para saber que estou lidando com essa struct! Se eu pudesse mencionar ela sem precisar saber de mais detalhes dela… como se fosse só um ponteiro… daria certo.

E é assim que podemos fazer o struct lista *next dentro de struct lista. Note que aqui a estrutura é nomeada, não mais anônima como foi no caso do ponto. E também que aqui sabemos que existe o tipo struct lista, mas ainda não fomos apresentados a Lista, portanto tentar fazer o seguinte é ilegal:

typedef struct lista {
    int value;
    Lista *next;
    // error: unknown type name 'Lista'
} Lista;

Como eu não posso mencionar ao elemento em si, não posso colocar o tipo de função que declarei como argumento de si mesmo. “Ah, mas é só um ponteiro!” Então, vai convencer o compilador! Melhor deixar quieto… porque existe um contorno para isso!

Apesar de não poder dizer qual o tipo perfeito, podemos dizer que o argumento é um ponteiro de função que retorna um inteiro: int (*)(). Os argumentos? Não decidido, então eu posso brincar.

Note que, em C, se eu quiser explicitar que a função não recebe argumento de jeito nenhum, preciso declarar ela com (void). No caso acima, algo como int (*)(void).

Então eu consigo fazer isso aqui:

typedef int (*Rec_int)(int (*r)(), int a, int b, int acc);

int _soma_rec(Rec_int r, int a, int b, int acc) {
    if (a > b) {
        return acc;
    }
    return r(r, a + 1, b, acc + (a % 2 == 0? 1: 0));
}

Muito bem, agora eu posso fazer a troca de estados! Vamos precisar de um tipo de função que recebe a função do estado par, a do estado ímpar, o começo do intervalo, o final do intervalo e o acumulado até então, e que retorne um inteiro:

typedef int (*Sum_f)(int (*parstate)(), int (*imparstate)(), int a, int b, int acc);

Ok, agora a função de entrada: se a for par, chamo logo a função do estado par; caso contrário, a função do estado ímpar:

int conta_pares(int a, int b) {
    Sum_f parst = _conta_pares_parstate;
    Sum_f imparst = _conta_pares_imparstate;

    Sum_f f_ini = a % 2 == 0? parst: imparst;
    return f_ini(parst, imparst, a, b, 0);
}

A função do estado ímpar só passa pra frente as coisas para o estado par, mudando apenas o a (como se ele tivesse feito o +1 mentalmente):

static int _conta_pares_imparstate(Sum_f parstate, Sum_f imparstate, int a, int b, int acc) {
    if (a > b) {
        return acc;
    }
    return parstate(parstate, imparstate, a+1, b, acc);
}

E, bem, sobre o estado par, basicamente chama o próximo estado com o acc alterado:

static int _conta_pares_parstate(Sum_f parstate, Sum_f imparstate, int a, int b, int acc) {
    if (a > b) {
        return acc;
    }
    return imparstate(parstate, imparstate, a+1, b, acc+1);
}

Recursão indireta

Ok, eu achei que ficou legal. Eu estou satisfeito com o meu serviço. Mas, falando sério, quem que vai codificar pensando em cálculo λ? Além de, bem, eu mesmo?

Vamos agora cogitar que teremos a chamada recursivamente, precisamos na função de entrada definir se vamos entrar em comportamento de que começamos a subir par ou ímpar:

int conta_pares(int a, int b) {
    int (*f_ini)(int a, int b, int acc) = a % 2 == 0? _conta_pares_parstate: _conta_pares_imparstate;
    return f_ini(a, b, 0);
}

O mais comum seria usar uma estratégia que já usamos anteriormente aqui nesse post: o poder de C que nos permite mencionar nominalmente coisas parcialmente conhecidas, por mais que não se sabe todos os detalhes.

Para isso, diferente do struct lista, precisamos fazer um “forward declaration”. O que quer dizer meio que “spoiler” do que vem a frente, sem de fato destrinchar o que vem na frente.

static int _conta_pares_imparstate(int a, int b, int acc);

Aqui eu posso mencionar chamar essa função, por mais que o compilador ainda não saiba quem é ela. Então eu posso definir _conta_pares_parstate:

static int _conta_pares_imparstate(int a, int b, int acc);

static int _conta_pares_parstate(int a, int b, int acc) {
    if (a > b) {
        return acc;
    }
    return _conta_pares_imparstate(a + 1, b, acc + 1);
}

Para a contagem de ímpares… bem, o _conta_pares_parstate já foi definido, não preciso fazer forward declaration:

static int _conta_pares_imparstate(int a, int b, int acc);

static int _conta_pares_parstate(int a, int b, int acc) {
    if (a > b) {
        return acc;
    }
    return _conta_pares_imparstate(a + 1, b, acc + 1);
}

static int _conta_pares_imparstate(int a, int b, int acc) {
    if (a > b) {
        return acc;
    }
    return _conta_pares_parstate(a + 1, b, acc);
}

Quem é mais poderoso, uma Máquina de Turing com fita limitada ou um Autômato Finito?

Wed, 25 Feb 2026 00:00:00 +0000

Inspirada nesta resposta do Stack Overflow em portugês.

Temos uma máquina de Turing. Ela é definida como contendo uma fita infinita, vide Uma demonstração de que Autômatos de Fila equivalem a Máquinas de Turing em poder computacional, parte 1. Mas, eu posso limitar o poder dela, posso limitar o tamanho da fita dela.

Inclusive, para toda linguagem sensível ao contexto, é possível criar uma máquina de Turing capaz de reconhecê-la com uma fita de Turing limitada linearmente ao tamanho da entrada (ie, uma fita de tamanho proporcional ao da palavra sendo reconhecida). Vide LBA, CSL.

Assim sendo, como demonstrar que um autômato finito (determinístico ou não) é menos poderoso do que uma máquina de Turing cuja fita não possa crescer?

Note que aqui não é um autômato finito versus um LBA em geral, mas sim uma máquina de Turing com uma fita de tamanho fixado pela entrada! A versão mais restrita de um LBA!

Já foi explorado aqui no blog o conceito de autômato finito, nas postagens Expressões regulares podem detectar números primos? e O que é um autômato?. Recapitulando rapidamente: um autômato finito (determinístico ou não) lê a entrada e a cada símbolo lido altera seu estado. Se chegar no final da entrada em um estado de aceitação, então a palavra pertence a linguagem. Caso contrário, a palavra não pertence a linguagem.

Para autômatos finitos sem transições lambda, toda alteração de estado envolve necessariamente consumir um símbolo da entrada. Independente de ser um λ-NFA, um NFA ou um DFA, todos possuem o mesmo poder computacional (aka, conseguem reconhecer o mesmo conjunto de linguagens). Vamos hoje assumir isso como um fato, a demonstração fica para um momento futuro.

Ok, agora como podemos demonstrar que a máquina de Turing, mesmo com a fita finita, consegue ser mais poderoso, menos poderoso, ou reconhecer algumas linguagens que um DFA não reconhece e o DFA reconhece algumas linguagens que essa máquina de Turing não reconhece?

Para isso, vamos começar com uma máquina de Turing no estado q1:

   q1
   V
aaabbb

Se ela escrever a na casa de leitura, mover pra trás e ir para o estado q2, vamos ter isso aqui:

  q2
  V
aaaabb

Podemos interpretar isso como uma função definida assim:

q1(b) ::= q2, a, <=

A primeira posição da tupla é o novo estado em que a máquina de Turing se encontra, a segunda posição da tupla é o conteúdo que o cabeçote de escrita escreve na fita e a terceira posição é o sentido que o cabeçote de leitura se move. No caso, para a terceira posição, só podemos ter dois valores possíveis, ou é => (direita) ou é <= (esquerda).

Certo, agora… vamos fazer umas limitações. A primeira é que não se pode ir além da entrada. Seria algo como:

  qx
  V
>aaabbb<

E as únicas transições aceitas para > (começo do input) ou para < (final do input) seriam do tipo:

qx(>) ::= >, qy, =>
qz(<) ::= <, qw, <=

Se chegou na borda, volta pra fita (potencialmente em outro estado). Se não tiver transições com esse símbolo também é considerado válido. A priori, já que sabemos que esses símbolos existem, vou simplesmente omitir eles das próximas representações, deixar eles implícitos.

Ok, limitamos o input. Agora, definimos que começamos sempre da posição logo após o começo da fita. No exemplo, para q0 o estado inicial, temos isso aqui:

q0
V
aaabbb

Com isso, temos o nosso autômato com a fita limitada do tamanho da entrada, sem direito a nem um gole de memória adicional.

Ok, até agora, tudo justo. E se eu limitar que eu sempre vou para a direita? Isso é, toda operação necessariamente retorna => como terceiro elemento da tupla. E, bem, já que o elemento jamais será lido novamente, podemos simplesmente manter ele, né? Então, assim, com essa nova limitação, todas as transições agora são do seguinte tipo:

qx(a) ::= a, qy, =>

Onde não há nenhuma relação sobre qx e qy. O que isso quer dizer? Bem, isso quer dizer que esse conjunto de regras aqui é válido:

q0(b) ::= b, qb1, =>
qb1(b) ::= b, qb2, =>
qb2(b) ::= b, qb2, =>
qb2(a) ::= a, qa, =>
qa(b) ::= b, damnation, =>

q0(a) ::= a, q0, =>
qb1(a) ::= a, q0, =>
qa(a) ::= a, q0, =>

q0(c) ::= c, q0, =>
qb1(c) ::= c, q0, =>
qb2(c) ::= c, q0, =>
qa(c) ::= c, q0, =>

Se q0, qb1, qb2 e qa forem estados de aceitação, e damnation não for estado de aceitação, então… bem, isso quer dizer estamos lidando com isso aqui!

Basicamente um autômato finito que reconhece toda palavra que tem como alfabeto {a, b, c} porém que não tenha a substring bbab.

Uma outra maneira de ler isso é transformar em transições gramaticais, onde cada estado se torna um não-terminal e toda transição que tem como produto um estado de aceitação se torna duas transições: uma com o estado (no caso de precisar ainda terminar de reconhecer a string) e outra sem o estado. Nesse exemplo, podemos escrever a seguinte BNF:

Q0 ::= b Qb1
Qb1 ::= b Qb2
Qb2 ::= b Qb2
Qb2 ::= a Qa
Qa ::= b Damnation

Q0 ::= a Q0
Qb1 ::= a Q0
Qa ::= a Q0

Q0 ::= c Q0
Qb1 ::= c Q0
Qb2 ::= c Q0
Qa ::= c Q0

Q0 ::= b
Qb1 ::= b
Qb2 ::= b
Qb2 ::= a

Q0 ::= a
Qb1 ::= a
Qa ::= a

Q0 ::= c
Qb1 ::= c
Qb2 ::= c
Qa ::= c

A produção Qa ::= b Damnation poderia ser omitida para indicar que não é aceita nessa gramática, mas o produto final é o mesmo já que para reconhecer não posso ter um não-terminal após as derivações da gramática. Mas o formalismo excessivo é para outro dia, aqui é formalismo em conta gotas.

Bem, como tivemos esse mapeamento para gramática generativa, podemos concluir de maneira inequívoca que de fato se trata de um autômato finito, é possível desenhar ele. Não garanto que ele seja sempre um autômato finito determinístico, como nesse exemplo bem desenhado acima, mas na pior das hipóteses vai ser um NFA.

Ok, posto isso, foi demonstrado que máquinas de Turing com fitas limitadas reconhecem todas as linguagens que autômatos finitos. Agora, precisamos de um caso de uma linguagem que seja possível reconhecer com uma máquina de Turing com fita limitada mas que seja impossível reconhecer sem caminhar para a esquerda. E, bem, tenho um fácil: uma string com a mesma quantidade de as e de bs!

Como funciona? Bem, ela inicia no estado neutro. Estando no estado neutro, ao ler um a ela entra em estado “procurando um b”, e vice-versa. Vou precisar de um marcador especial de fita, chamado de x, que simplesmente indica que aquele elemento da memória já foi lido. O x vai servir apenas para uma coisa: permitir ignorar essa casa enquanto se procura o próximo elemento.

Ao entrar em modo “procurando um a”, vamos ignorar todo a encontrado e passar pra frente, tal qual fazemos com x também. Ao encontrar um b, substituímos esse b por x para indicar que esse símbolo já foi consumido, mudamos o estado para retorno e andamos para a esquerda. Nesse estado retorno vamos andando para a esquerda até achar um marcador y. Ao achar esse marcador y, substitui ele por x e anda para a direita, agora de volta ao estado neutro. Se chegou no final da string no estado neutro, reconhece a linguagem!

Ah, esse y é colocar ao sair do estado neutro!

Vamos escrever aqui como seria essa linguagem:

q0(x) ::= x, q0, =>    # esse símbolo já foi usado, ignora
q0(a) ::= y, qb, =>    # estado "procurando b"
q0(b) ::= y, qa, =>    # estado "procurando a"

qa(a) ::= x, qR, <=    # achou o "a", retornando
qb(b) ::= x, qR, <=    # achou o "b", retornando

qa(x) ::= x, qa, =>    # esse símbolo já foi usado, ignora
qb(x) ::= x, qb, =>    # esse símbolo já foi usado, ignora

qa(b) ::= b, qa, =>    # não é o símbolo que procuro, ignora
qb(a) ::= a, qb, =>    # não é o símbolo que procuro, ignora

qR(a) ::= a, qR, <=    # segue retornando!
qR(b) ::= b, qR, <=    # segue retornando!
qR(y) ::= x, q0, =>    # achei o ponto marcado de início da busca

Como essa linguagem não pode ser reconhecida por um autômato finito, achei um exemplo de linguagem que a máquina de Turing, mesmo com a fita limitada, reconhece e que está fora da capacidade de reconhecimento dos autômatos finitos.

E, bem, essa demonstração de que essa linguagem não é possível ser reconhecida por um autômato finito fica para um outro post!

Indo um passo além

Até aqui eu demonstrei apenas a capacidade de reconhecer linguagens além das linguagens regulares. E escolhi um exemplo que acaba sendo equivalente a uma linguagem livre de contexto. Então, que tal ir além? E se eu conseguir demonstrar que é possível reconhecer linguagens que não são limitadas a linguagens livres de contexto? Isto é, que a máquina de Turing com a fita limitada reconhece coisas que seriam impossíveis para um autômato de pilha?

Bem, o exemplo mais clássico é: reconhecer uma palavra, em um alfabeto com 2 ou mais letras, que aparece exatamente duas vezes. Algo como p p, para p in {a, b}*.

Bem, aqui temos um caso bem bacana para resolver, porque agora, ao procurar por um a, eu preciso simplesmente ter a opção de ignorar e ir em frente. Afinal, essa palavra: abbaaabbaa está na linguagem, é a repetição da palavra abbaa.

Minha sugestão é trabalhar com uma parte não-determinística, a de fazer a primeira marcação “aqui começa a outra palavra”, e depois tratar como determinístico. Temos o estado neutro, que ainda está no não-determinismo, que vai evoluir para um “procurando algum a não-deterministicamente” ou para “procurando algum b não-deterministicamente”. A diferença é que, ao achar o elemento que procura, ele vai ter três opções:

chegar no final da leitura
ignorar e continuar a busca não-determinística
marcar aquilo com um W para indicar o começo da palavra duplicada

Bem, se chegou no final da leitura sem encontrar nada… recusa a palavra…

Após marcar com W, ele vai voltar até a marca y. Após achar a marca y, ele vai continuar a direita, e vamos ter duas opções aqui:

acha um W, indicando que “terminou” a primeira palavra
acha uma letra da entrada, então precisa procurar pela equivalente “do outro lado”

Para o caso de achar o W, isso significa que de fato encontramos algo com o formato p p, mas não necessariamente apenas isso… Nessa situação, precisa validar até o final de que só se lê símbolos usados. Se chegou no final e só tem símbolos usados, então sim, é uma palavra formada pela concatenação da palavra p com ela mesma (p p). Mas, se achar outra coisa, isso significa que o que estamos lendo é algo na forma p p q, onde q in {a, b}*, |q| > 0, e portanto está fora da nossa linguagem.

Ok, e no caso de achar uma letra? Agora vamos procurar por essa letra “do outro lado”. Isso significa entrar em um estado que só vai indo para frente até encontrar o W. E agora ele ignora símbolos usados até achar o que precisa. Se achou algo que não foi um símbolo usado ou o símbolo que ele procura, então não é uma palavra da forma p p, portanto recusa a palavra. Nessa situação, pode até ser algo no formato qa g qb y, onde foi identificado que a subpalavra q até apareceu aqui e lá, porém em algum momento onde era esperado encontrar um a foi encontrado um b (aqui g e y são qualquer coisa, não foi verificado), tudo isso com q, g, y in {a, b}*, |q| > 0.

Aqui, o estado inicial e o estado de equilíbrio na busca de resíduos são estados de aceitação, todos os outros não. Vou criar um estado qQ só para indicar que a entrada foi recusada explicitamente.

O estado inicial é q0, o estado de equilíbrio é q=. As buscas não determinísticas vão ser qna e qnb, só para diferenciar de qa e qb, botando esse n na frente para indicar o “não-determinismo”. Para avançar até encontrar o separador W, vou indicar com os estados qwa e qwb. O estado q~ indica a busca por resíduos.

q0(a) ::= y, qna, =>         # preciso achar uma subpalavra que começa com "a"
q0(b) ::= y, qnb, =>         # preciso achar uma subpalavra que começa com "b"

qna(a) ::= a, qna, =>        # ignorei esse "a", pego um próximo
qna(a) ::= W, qr, <=         # vou considerar esse "a" em específico como começo da subpalavra
qnb(b) ::= b, qnb, =>        # ignorei esse "b", pego um próximo
qnb(b) ::= W, qr, <=         # vou considerar esse "b" em específico como começo da subpalavra

qna(b) ::= b, qna, =>        # não procuro "b"
qnb(a) ::= a, qnb, =>        # não procuro "a"

qr(a) ::= a, qr, <=          # estou retornando para a marcação
qr(b) ::= b, qr, <=          # estou retornando para a marcação
qr(x) ::= x, qr, <=          # estou retornando para a marcação
qr(W) ::= W, qr, <=          # estou retornando para a marcação
qr(y) ::= x, q=, =>          # achei a marcação! estou em equilíbrio

q=(W) ::= W, q~, =>          # ok, acho que acabou, vamos procurar resíduos
q~(x) ::= x, q~, =>          # até agora tudo conforme esperado
q~(a) ::= a, qQ, =>          # puts, achei resíduo, recusando!
q~(b) ::= b, qQ, =>          # puts, achei resíduo, recusando!

q=(a) ::= y, qwa, =>         # preciso achar um "a" do outro lado!
q=(b) ::= y, qwb, =>         # preciso achar um "b" do outro lado!

qwa(a) ::= a, qwa, =>        # ainda não cheguei do outro lado...
qwa(b) ::= b, qwb, =>        # ainda não cheguei do outro lado...

qwa(W) ::= W, qa, =>         # cheguei do outro lado, a busca verdadeira começou!
qwa(W) ::= W, qb, =>         # cheguei do outro lado, a busca verdadeira começou!

qa(a) ::= x, qr, <=          # achei o "a" que eu procurava, retornando
qb(b) ::= x, qr, <=          # achei o "b" que eu procurava, retornando

qa(b) ::= b, qQ, =>          # achei algo errado! recusando!
qb(a) ::= a, qQ, =>          # achei algo errado! recusando!

qa(x) ::= x, qa, =>          # esse símbolo já foi usado, o que procuro está adiante...
qb(x) ::= x, qb, =>          # esse símbolo já foi usado, o que procuro está adiante...

Para reconhecer a palavra abbaaabbaa, seria mais ou menos assim (vou ignorar as transições de estado que só estão indo pra lá ou pra cá sem rumo, e só vou mostrar o caso que dá certo):

q0
V
abbaaabbaa

Consome o a e inicia a busca não-determinística de um a:

 qna
 V
ybbaaabbaa

Achou o a perfeito:

     qna
     V
ybbaaabbaa

Vamos voltar pro começo marcando o possível começo da subpalavra…

    qr
    V
ybbaaWbbaa

Ok, estamos em equilíbrio…

 q=
 V
xbbaaWbbaa

Encontramos um b…

  qwb
  V
xybaaWbbaa

Vou só mostrar aqui a transição para “o outro lado”:

     qwb
     V
xybaaWbbaa

E pronto, do outro lado! Podemos procurar um b:

      qb
      V
xybaaWbbaa

E voltamos…

     qr
     V
xybaaWxbaa

 qr
 V
xybaaWxbaa

  q=
  V
xxbaaWxbaa

   qwb
   V
xxyaaWxbaa

Como prometido, indo até o ponto que achou o que queria…

       qb
       V
xxyaaWxbaa

      qr
      V
xxyaaWxxaa

  qr
  V
xxyaaWxxaa

   q=
   V
xxxaaWxxaa

    qwa
    V
xxxyaWxxaa

Notou como ignorou os x?

        qa
        V
xxxyaWxxaa

       qr
       V
xxxyaWxxxa

   qr
   V
xxxyaWxxxa

    q=
    V
xxxxaWxxxa

     qwa
     V
xxxxyWxxxa

         qa
         V
xxxxyWxxxa

        qr
        V
xxxxyWxxxx

    qr
    V
xxxxyWxxxx

E, finalmente, o estado de equilíbrio…

     q=
     V
xxxxxWxxxx

Hora de buscar resíduos!!

      q~
      V
xxxxxWxxxx

E não achou nada de resíduo… portanto, palavra reconhecida!

          q~
          V
xxxxxWxxxx

Reconhecemos a ocorrência da palavra formada pela concatenação de uma palavra com ela mesma, coisa que não é possível fazer com um simples autômato de pilha. Portanto, máquinas de Turing, mesmo com fitas limitadas, conseguem reconhecer linguagens além das linguagens livres de contexto!

Notas sobre ser mais poderoso do que autômato de pilhas

Ok, demonstrei que a máquina de Turing, mesmo com a fita limitada, reconhece linguagens além das livres de contexto. Agora, vou dar uma noção de que mesmo esse modelo limitado de máquina de Turing é capaz de reconhecer todas as linguagens livres de contexto.

Para começar, vamos tomar como exemplo uma linguagem que produz palíndromos no alfabeto {a, b}:

S ::= a S a
S ::= b S b

S ::= a a
S ::= b b

S ::= a
S ::= b

Pronto, só isso. Essa simples gramática gera todos os palíndromos possíveis no alfabeto {a, b}. Agora, vamos usar como resultado que toda gramática livre de contexto tem uma gramática “equivalente” (não no sentido esturtural, mas no sentido de que gera a mesma linguagem, o mesmo conjunto de palavras) na forma normal de Chomsky.

Resumindo fica assim:

S ::= A SA
SA ::= S A
S ::= B SB
SB ::= S B

S ::= A A
S ::= B B

S ::= a
S ::= b
A ::= a
B ::= b

Basicamente aqui vou aplicar um processo não-determinístico: como a produção de um não-terminal para um terminal acontece sempre 1:1 na forma normal de Chomsky, primeiro eu tento advinhar quais eram os não terminais que geraram aquela palavra. Por exemplo, ababa, tem um caso que não deriva de S que é A B A B A, e um caso que de fato deriva de S que é A B S B A. Em seguida, vou percorrendo de alto a baixo procurando dois não terminais que eu sei que vem de uma produção. Por exemplo, S B vem de SB. Ao achar um desses pares, eu faço a substituição do segundo elemento pelo “elemento que produziu”, então movo para a esquerda e transformo aquilo em uma espécie de “expurgo” X: A B S B A viraria A B S SB A e em seguida A B X SB A. Com o expurgo produzido, eu dou um jeito de mover o expurgo para o canto: A B SB A X. Após mover ele para o canto, eu o ignoro e sigo achando as transformações adequadas. Nesse caso aqui, seria B SB que se transforma em S. Fazendo a transformação e ignorando o expurgo, tenho A S A. Então, S A percebo que é SA: A SA. Então, A SA percebo que é S. Finalmente, cheguei no elemento inicial da gramática, portanto essa palavra é válida.

Para fazer esse reconhecimento foram precisos muitos estados, mas não foi preciso escrever nada além dos limites da entrada. Portanto, toda gramática livre de contexto na forma normal de Chomsky é possível de se reconhecer sem necessitar usar memória além do input. E como toda linguagem livre de contexto possui necessariamente pelo menos uma gramática livre de contexto, e toda gramática livre de contexto pode ser transformada na forma normal de Chomsky, é seguro afirmar que essa máquina de Turing com fita limitada consegue reconhecer todas as linguagens livres de contexto.

Organizando tags

Tue, 24 Feb 2026 00:00:00 +0000

Uma coisa que eu sempre tive curiosidade de fazer era saber qual a tag que uso com mais frequência aqui no computaria. E, também, por que não, poder olhar em ordem as tags mais utilizadas.

Então, vamos ordenar a lista de tags?

Esquema geral

Atualmente, a ordenação das posts é em ordem alfabética. Então, se eu quero ordenar com quantidade de posts, eu também devo conseguir retornar a lista original. Então devo ser capaz de ordenar de ordem decrescente de posts e ordem alfabética (ou, de certo modo, “crescente”) de nomes.

Logo, por questão de completude, vou querer ordenar de modo crescente/decrescente tanto por quantidade de posts como por nome das tags.

Para fazer essa ordenação, não gostaria de depender de nada além do que existe como atributo nas tags. Portanto, vamos lá usar datasets!

Como a UI não está bem consolidada, irei colocar botões para essa ordenação bem feios. Daí, essas coisas não podem vir a ser algo “prod-like”, vamos considerar essa incursão como algo beta até ficar devidamente limado.

Se quiser ver como que ficou, pode clicar aqui (tags com beta ligado).

Além do mais, gostaria de que um atributo fosse alterado e, em cima desse atributo, a árvore se ordenasse. Eu deveria escutar o atributo do <ul> que tem a listagem das tags.

A criação do HTML

Para lidar com as questões necessárias de dados para a ordenação, primeiro eu preciso povoar dentro do próprio HTML. Como a página de tags foi transportada para um layout a ser povoado (checar a última seção do post Aliases de tags no Computaria), era exatamente ali que eu precisava mexer: tags.html.

Para começar, vamos identificar o <ul> com um id: tag-list. Dentro dessa tag, o Liquid para gerar os itens é:

{% for tag in page.sitetags %}
    <li>
        <span class='post-meta'>{{ tag.posts.size }} posts</span>
        <h2>
            <a class='post-link beta-link' href='{{ tag.url | prepend: site.baseurl }}'>{{ tag.tag }}</a>
        </h2>
    </li>
{% endfor %}

Bem, aparentemente tenho tudo que eu preciso aí já! Posso pegar a quantidade de posts com e o nome com. Como o elemento que vai ser ordenado vai ser o item da lista, vou colocar essas informações no <li>:

<li data-name='{{ tag.tag }}' data-size="{{ tag.posts.size }}">

Ficou interessante. Aparentemente, tudo resolvido, né? Só que… bem, algumas tags tem coisas inconvenientes, como destaquei no post Usando as tags - Parte 1: página de tags:

Hmmm, algumas coisas não ficaram legais. Para garantir uma bela ordenação, resolvi que deveria comparar com “lowercase”. Depois percebi que o acento em álgebra estava atrapalhando. Daí foi mal fácil resolver esse problema de imediato com o á trocando-o por a

Ou seja, os acentos estavam dando problema já naquela época! Como eu poderia lidar com isso agora em ambiente puramente Liquid? Descobri que existe uma opção em slugify que faz isso: slugify: "latin":

<li data-name='{{ tag.tag | slugify: "latin" }}' data-size="{{ tag.posts.size }}">

Para finalizar, podemos deixar a página consistente em relação a o como ela vem ordenada com o atributo de ordenação. Então, o <ul>, que vai ser identificado para poder ser melhor manipulado, vai vir com um atributo específico para indicar a ordenação, atributo isso que irei escutar. Então, para indicar que estou ordenando de maneira alfabética nos títulos, e que está crescente, escolhi colocar o seguinte como essa indicação: data-sorted="alpha:↑".

Aqui, o atributo é indicado como data-sorted, acessado como element.dataset.sorted. Usei alpha para indicar ordenação alfabética. Isso é o suficiente para no contexto indicar ordenação alfabética pelo nome da tag, ao menos na minha visão. Usei também a seta ↑ para indicar que está crescendo, que vai aumentando. E também um separador, :, para indicar como o dado está estruturado: um identificador de tipo, e a seta indicando se “cresce” ou se diminui.

Encodando a ordenação

Já ficou mais ou menos claro como é o esquema da ordenação, né? Basicamente eu tenho o tipo de coisa que irei ordenar, um separador, e a direção da ordenação.

E podemos representar isso através de uma tipagem em TypeScript! Então, por que não, né? Não iremos usar o TS na página, mas exibindo aqui como mecanismo de pensamento, modelagem do problema.

Para fazer isso, preciso primeiro definir os tipos de campo e de seta, por assim dizer. Eles são bem simples, alpha para os títulos, em ordem alfabética, e num para a contagem de posts:

type Field = "alpha" | "num";

Um tipo de constantes bem definido, joia! E sobre as setas, eu tenho a seta pra cima e a seta pra baixo, indicando “ordem crescente” e “ordem decrescente”:

type Arrow = "↓" | "↑";

Agora, para o tipo da ordenação em si, preciso pegar o tipo Field, concatenar com o literal :, e por fim concatenar com o tipo Arrow. Felizmente o TS já previu esse tipo de necessidade com o “template literal types”:

type Field = "alpha" | "num";
type Arrow = "↓" | "↑";
type Sort = `${Field}:${Arrow}`;

Para testar, posso tentar inicializar uma variável do tipo Sort com algum valor arbitrário:

const ordenaTitulos: Sort = "alpha:↓";

Validando a string de ordenação

O campo data-sorted está definido como se fosse do tipo Sort. Agora, como validar se é desse tipo mesmo? Uma alternativa até simples:

cortar a string no separador :
verificar se tem exatamente 2 elementos após o split
verificar que o primeiro elemento é alpha ou num
verificar que o segundo elemento é uma seta, ↓ ou ↑

Basicamente, essa função aqui:

function validSortStuff(sortCondition) {
    const {type, arrow, etc} = sortStuffAsObject(sortCondition)

    if (etc.length != 0) {
        return false
    }
    switch (arrow) {
        case "↓":
        case "↑":
            break
        default:
            return false
    }
    switch (type) {
        case "alpha":
        case "num":
            return true
        default:
            return false
    }
}

function sortStuffAsObject(sortCondition) {
    const [type, arrow, ...etc] = sortCondition.split(":");
    return {
        type,
        arrow,
        etc
    }
}

Note que estou colhendo o corte em cima do : com a desestruturação do array, [type, arrow, ...etc] = sortCondition.split(":"), então já retorno em um objeto com uso um pouco mais semântico do que ficar usando parts[0] para indicar o tipo da ordenação ou parts[1] para indicar a seta. E estou colhendo o etc justamente para garantir a inexistência de 3º campo (ou além, caso existam mais).

Escutando a mudança

Eu gostaria de mudar apenas quando um atributo fosse alterado. Então, para fazer a alteração do atributo, criei os botões adequados:

<div class="beta beta-hidden" data-beta="hidden">
    <button onclick="sortPosts('num:↑')">↑ sort by #</button>
    <button onclick="sortPosts('num:↓')">↓ sort by #</button>

    <button onclick="sortPosts('alpha:↑')">↑ sort by a-z</button>
    <button onclick="sortPosts('alpha:↓')">↓ sort by z-a</button>
</div>

Onde defino sortPosts da seguinte maneira:

function sortPosts(sortCondition) {
    if (!validSortStuff(sortCondition)) {
        console.log(`<${sortCondition}> não é válido`)
        return
    }
    const element = document.getElementById("tag-list")
    if (element.dataset.sorted != sortCondition) {
        element.dataset.sorted = sortCondition
    }
}

Então, pesquisando exatamente por “disparar função quando alterar atributo no DOM”, cheguei neste artigo How to ‘listen’ for attribute changes in JavaScript. Basicamente, criar um MutationObserver, botar ele pra observar um elemento e dizer que quer observar mudanças de atributos.

Então, vamos brincar com o MutationObserver?

const observer = new MutationObserver((mutationList, observer) => {
    console.log("mudou")
}

observer.observe(document.getElementById("tag-list"), { attributes: true })

Show! Consigo ver que a função foi disparada no clique do botão! Agora, vamos investigar a questão dessa lista de mutação? Eu poderia ler a documentação mas eu prefiro mexer com REPL… Sou ligeiramente suspeito… Evidência 1, 2, 3 e a prova definitiva em que saí totalmente do caminho para habilitar o REPL onde normalmente não teria na evidência 4. Eu quero que o valor desse objeto esteja acessível no meu console da web, então como eu faço isso? Simplesmente faço uma atribuição arbitrária:

const observer = new MutationObserver((mutationList, observer) => {
    console.log("mudou")
    myGrandGlobal = mutationList
}

observer.observe(document.getElementById("tag-list"), { attributes: true })

Note que usar let deixaria no escopo da função. E que usar o var não vai permitir acessar fora da função (mas deixaria acessível abaixo da função). Então, é assim que se declara globais em javascript? Sim, você simplesmente atribui para um nome que não está definido no escopo. E com isso eu consigo facilmente puxar no console da web o que tem em seu conteúdo:

Bem, ele normalmente vem só com um único elemento, mas não custa nada iterar na lista, né? Ele também traz o target que houve a alteração, o tipo da alteração que foi disparado, e também, quando é uma alteração de atributo, o nome do atributo que sofreu alteração.

No caso, como eu já estou colocando apenas no elemento desejado (via document.getElementById("tag-list")), não preciso validar o target específico. Eu também pedi para observar apenas em situações de alterações de atributos (no observer.observe(elemento, { attributes: true })). Então, não preciso validar essas coisinhas. Mas o nome do atributo? Esse sim.

A propósito, nos meus testes o mutationRecord.oldValue estava sempre nulo 🤷‍♂️. Na documentação desse atributo em específico na MDN, ele lista que precisa passar { attributes: true, attributeOldValue: true } como argumento de observer.observe.

Então, aqui, eu preciso simplesmente filtrar aquilo que eu desejo. Poderia fazer mutationList.filter, mas meu instinto primordial me fez fazer um loop clássico:

for (const mutation of mutationList) {
    // precisamos ter certeza que é o atributo "data-sorted"
    if (mutation.attributeName != "data-sorted") {
        continue;
    }
    const tag = mutation.target;
    const sortCondition = tag.dataset.sorted;

    // ...
}

Muito bem, já selecionei apenas as mutações do target correto (que não preciso recuperar do DOM, já está ali), e cuja alteração foi no atributo correto. Agora preciso aplicar a ordenação. Mas, como eu posso fazer isso?

Primeiro, porque não custa nada, podemos validar que o sortCondition está válido. Então, extrair as informações do tipo da ordenação e o sentido:

// verificando se tá válido mesmo
if (!validSortStuff(sortCondition)) {
    console.log(`ordenação inválida [${sortCondition}], ignorando`);
    continue;
}
const sortStuff = sortStuffAsObject(sortCondition);

Em cima do sortStuff eu consigo elaborar uma função para ordenar as tags. E, bem, já que os dados estão dentro das tags, que tal ter uma função para extrair o atributo a ser ordenado em cima de sortStuff.type e definir o sentido da ordenação através do sortStuff.arrow. Em cima disso, posso definir uma forma de ordenação como uma função de alta ordem:

const extractor = extractSortingAttribute(sortStuff.type);
const comparor = extractComparor(sortStuff.arrow);
const sortFunction = (a, b) => {
    const aAttr = extractor(a);
    const bAttr = extractor(b);
    return comparor(aAttr, bAttr);
};

Ok, agora sabemos como ordenar (por mais que o como vou extrair o valor da tag esteja abstraído agora, e por mais que o detalhe do sentido da ordenação esteja também abstraído), precisamos saber o que ordenar.

No caso, baseado no myGrandGlobal[0].target, o melhor jeito seria pegando myGrandGlobal[0].target.children. Esse método retorna os nodos filhos do HTML bem bonitinho, já myGrandGlobal[0].target.childNodes retorna até detalhes como os espaços em branco do HTML entre o <ul> e o primeiro <li>, ou entre o </li> e o <li> seguinte, informações não necessárias. Portanto, pego o tag.children. Isso retorna um objeto do tipo HTMLCollection, que posso trivialmente transformar em um Array usando Array.from. Agora, com um Array, eu posso simplesmente aplicar o .sort e ser feliz!

Com as coisas ordenadas, eu posso seguir o mesmo raciocínio aplicado ao randomizar a aparição dos podcasts em Refatorando página de podcasts: remover todos os elementos e depois readicionar eles como filhos do nó:

const childrenArray = Array.from(tag.children);

childrenArray.sort(sortFunction);

for (const child of childrenArray) {
    tag.removeChild(child)
}
for (const child of childrenArray) {
    tag.appendChild(child)
}

Muito bem, juntando tudo eu tenho isso:

const observer = new MutationObserver((mutationList, observer) => {
    for (const mutation of mutationList) {
        // precisamos ter certeza que é o atributo "data-sorted"
        if (mutation.attributeName != "data-sorted") {
            continue;
        }
        const tag = mutation.target;
        const sortCondition = tag.dataset.sorted;

        // verificando se tá válido mesmo
        if (!validSortStuff(sortCondition)) {
            console.log(`ordenação inválida [${sortCondition}], ignorando`);
            continue;
        }
        const sortStuff = sortStuffAsObject(sortCondition);

        const extractor = extractSortingAttribute(sortStuff.type);
        const comparor = extractComparor(sortStuff.arrow);
        const sortFunction = (a, b) => {
            const aAttr = extractor(a);
            const bAttr = extractor(b);
            return comparor(aAttr, bAttr);
        };

        const childrenArray = Array.from(tag.children);

        childrenArray.sort(sortFunction);

        for (const child of childrenArray) {
            tag.removeChild(child)
        }
        for (const child of childrenArray) {
            tag.appendChild(child)
        }
    }
})

observer.observe(document.getElementById("tag-list"), { attributes: true })

Esclhendo o sentido

Vamos ordenar agora pelo nome da tag. Vou ignorar completamente o como o atributo é resgatado, mas assumindo que eles vão estar resgatador. Então, basicamente vou assumir que eu tenho o atributo, que vou estar comparando ele, e que eu preciso definir, com a ajuda do arrow, definir como organizar.

Vamos fazer um operador de ordenação natural?

const baseCmp = (a, b) => {
    if (a < b) {
        return -1;
    } else if (a > b) {
        return +1;
    }
    return 0;
}

Se eu quiser ordenar no sentido contrário? Bem, eu inverto a ordem dos argumentos e envio para o ordenador base, a ordenação natural:

(a, b) => baseCmp(b, a)

Agora, para saber se uso a ordenação natural ou a ordenação natural invertida, eu preciso verificar o arrow que é passado. Se for crescente, eu uso o baseCmp. Se for decrescente, uso o invertido:

function extractComparor(arrow) {
    const baseCmp = (a, b) => {
        if (a < b) {
            return -1;
        } else if (a > b) {
            return +1;
        }
        return 0;
    };
    if (arrow == "↑") {
        return baseCmp
    }
    return (a, b) => baseCmp(b, a);
}

Extraindo o atributo

Basicamente, eu preciso receber uma tag HTML e puxar um atributo dentro do dataset. Bem, e eu ainda preciso extrair de modo que eles sejam ordenados naturalmente, o que significa que eu preciso diferenciar 1 de "1" (afinal, 10 > 2, mas "10" < "2").

Eu tenho dois casos para isso:

alpha: extrai a propriedade name
num: extrai a propriedade size, como um número

Então, posso simplesmente extrair dessa maneira:

function extractSortingAttribute(type) {
    if (type == "alpha") {
        return (n) => n.dataset.name;
    }
    return (n) => Number(n.dataset.size)
}

Resultado final

Bem, esse é o design inicial. Você pode encontrar ele nas tags com beta ligado, pelo menos até uma versão mais final da interface. No futuro, independente de como vai ficar, os princípios vão se manter:

pegar o tag-list
observar quando o data-sorted for alterado
extrair as propriedade desejadas dos list items
ordenar
reinserir o conjunto ordenado em tag-list

Detalhes podem mudar? Podem. Talvez um link com um query param para compartilhar com os outros como que fica a listagem? (Vide Manipulando query string para melhor permitir compartilhar uma página carregada dinamicamente). Provável.

Também posso eventualmente mudar o nome dos atributos para resgatar mais diretamente do datase, ou mesmo deixar de usar setas literais e passar a usar algo como ascending ou descending.

Mas o coração vai ficar aí, só esperando para consolidar e sair do beta.

Pequeno template em Node para programação competitiva

Sat, 21 Feb 2026 00:00:00 +0000

Abri o Spoj e resolvi fazer um pouco de flex com Node pelo bel prazer de resolver as coisas com JavaScript, quick n’dirt. E, bem… me deparei com um problema que eu não havia ainda cuidado: como faço para ler da entrada padrão no Node?

Objetivo

Agora, eu preciso fazer um template para usar no Spoj. A ideia é ter uma espécie de mini-boilerplate estilo o que foi fornecido nessa resposta. Por que fazer um template distinto? Porque não gostei desse, achei pouco intuitivo para mim.

Aqui a solução que o autor publicou:

// Source - https://stackoverflow.com/a/79416756
// Posted by bikeman868
// Retrieved 2026-02-20, License - CC BY-SA 4.0

const partialLine = '';
const lines = [];
const emitter = new EventEmitter()

process.stdin.on('data', (data) => {
  const buffer = this._partialLine + data
  const newLines = buffer.split('\n')
  partialLine = newLines.pop() || ''
  lines.push(...newLines)
  if (lines.length) this._emitter.emit('data')
})

Por que eu não gostei? Porque aqui eu preciso fazer uma magia com o emitter, tem muito estado do boilerplate que tá como estado global. Enfim, eu queria algo mais direto, algo como:

// resolve o problema

// define a magica

process.stdin.on('data', magica.on(solveProblemLinePerLine))

E nessa brincadeira a função solveProblemLinePerLine recebe uma linha de cada vez.

Ah, por que esse process.stdin.on('data', ...)?

Vamos por partes:

process é um objeto que carrega dados sobre o processo em si
stdin é a stream que representa a entrada padrão
.on('data', ...) é uma reação de evento de quando recebeu um dado (ou seja, de fato fez uma leitura)

Então, se eu não puser um wrapper bonito na frente, é com isso que eu preciso lidar. E, bem, meu objetivo é passar a linha inteira para frente, né? Vamos abstrair como isso é feito e pensar em soluções de problemas?

A vida, o universo e tudo mais

O primeiro problema do Spoj é um problema bem simples: repita o número informado, até encontrar o primeiro 42. A partir de então, ignore todos os números até o fim, incluindo o 42. Por exemplo, para a entrada:

A saída será:

1
2
88

Como fazer isso? Podemos fazer uma máquina de estados, em que tem um estado inicial GO e que, ao receber o valor 42, transita para o estado STOP. Se a transição não ocorrer, emite o mesmo símbolos que recebeu.

let state = "GO";
function solveProblemLinePerLine(line) {
    if (line == "42") {
        state = "STOP";
    }
    if (state == "STOP") {
        return;
    }
    console.log(line);
}

Como posso testar isso? Simples: passo cada linha manualmente!

solveProblemLinePerLine("1");
solveProblemLinePerLine("2");
solveProblemLinePerLine("88");
solveProblemLinePerLine("42");
solveProblemLinePerLine("99");

Essa questão aceita que você submeta uma resposta em Node para ela!

Gerador de primos

Aqui estou me baseando no problema Prime Generator, mas que infelizmente não aceita submissão em Node.

Na primeira linha, é informada a quantidade de casos de casos de teste, T. Para cada uma das T linhas seguintes, é informado um caso de teste que consiste de 2 números, m e n. A ideia é imprimir, para cada caso de teste, todos os primos p tal que m <= p <= n, e, ao final de um caso de testes, imprimir uma linha em branco.

Por exemplo, para a entrada:

2
1 10
3 5

Temos a saída:

Como fazer isso? Bem, no primeiro momento, temos o estado INIT, então eu entro no estado INSTANCE. Eu todo T vezes no estado INSTANCE, então após esse tempo irei para o estado END e encerro o processo.

Então, posso colocar essa máquina de estados de modo geral na função solveProblemLinePerLine:

let state = "INIT";
let nProblems = 0;

function solveProblemLinePerLine(line) {
    switch (state) {
        case "INIT":
            readNProblems(Number(line));
            state = "INSTANCE";
            break;
        case "INSTANCE":
            const s = line.split(" ")
            readInstance(Number(s[0]), Number(s[1]));
            console.log();
            nProblems--;
            if (nProblems == 0) {
                state = "END";
                process.exit(0)
            }
            break;
    }
}

Na primeira leitura, eu transformo essa linha em um número e passo para quem de fato lida com o estado. Então, altero o estado para INSTANCE.

Nas próximas leituras, eu sei que são 2 números, separados por um espaço. Então eu separo a linha pelo espaço e transformo em números essas duas partes, transmitindo esses números para quem de fato lida com isso. Após isso, eu imprimo a linha vazia que separa cada instância e subtraiu da quantidade de instâncias restante. Se a quantidade chegou em zero, muda o status para END e termino a execução do programa.

Agora, com isso em mente, como lidamos com as partes abertas? Bem, não vou tratar de modo esperto. No caso de readNProblems eu simplesmente povoo a variável nProblems. Poderia colocar isso no switch do solveProblemLinePerLine? Claro! Mas meu pensamento estava em tratar os estados, eu quis separar isso por design mesmo.

Então, eu tenho o readInstance. Aqui eu preciso iterar do começo ao fim (incluso) e, para cada primo encontrado, imprimir ele. Vou para a solução mais tosca mesmo:

function readInstance(menor, maior) {
    for (let i = menor; i <= maior; i++) {
        if (isPrime(i)) {
            console.log(i);
        }
    }
}

Agora eu preciso resolver isPrime. Bem, aqui eu poderia usar o Crivo de Eratótenes, algumas soluções mais interessantes, ou simplesmente validar dividindo pelos números menores. Como a ideia é ser simples, não vou focar em como fazer isso, vou pelo jeito bruto. Se é menor do que ou igual a 1, não é primo. Se é 2, é primo. Se é par, não é primo. Depois, de i a partir do 3 e incrementando de 2 em dois até que i*i seja maior do que o número em questão; se em algum momento esse i dividir o número em questão, então o número em questão não é primo. Se chegou no final dessa iteração, então o número é primo:

function isPrime(p) {
    if (p <= 1) {
        return false;
    }
    if (p == 2) {
        return true;
    }
    if (p % 2 == 0) {
        return false;
    }
    for (let i = 3; i * i <= p; i += 2) {
        if (p % i == 0) {
            return false;
        }
    }
    return true;
}

Juntando tudo:

let state = "INIT"
let nProblems = 0

function readNProblems(n) {
    nProblems = n
}

function isPrime(p) {
    if (p <= 1) {
        return false;
    }
    if (p == 2) {
        return true;
    }
    if (p % 2 == 0) {
        return false;
    }
    for (let i = 3; i * i <= p; i += 2) {
        if (p % i == 0) {
            return false;
        }
    }
    return true;
}

function readInstance(menor, maior) {
    for (let i = menor; i <= maior; i++) {
        if (isPrime(i)) {
            console.log(i);
        }
    }
}

function solveProblemLinePerLine(line) {
    switch (state) {
        case "INIT":
            readNProblems(Number(line));
            state = "INSTANCE";
            break;
        case "INSTANCE":
            const s = line.split(" ")
            readInstance(Number(s[0]), Number(s[1]));
            console.log();
            nProblems--;
            if (nProblems == 0) {
                state = "END";
                process.exit(0)
            }
            break;
    }
}

Testando:

solveProblemLinePerLine("2");
solveProblemLinePerLine("1 10");
solveProblemLinePerLine("3 5");

Implementando a mágica

Beleza, eu preciso pegar os eventos de dados, transformar ele em linhas e passar essas linhas adiante. Eventualmente meus dados não terão uma linha completa, então sempre o último elemento fica como resíduo. Felizmente, para os casos de programação competitiva tradicionais, a entrada é bem formatada e sempre termina com uma quebra de linha, não tem resíduo após a última quebra de linha.

Então eu preciso de uma função, que internamente tenha um eventual resíduo que se aproveita entre runs seguidas. Essa função recebe os dados e emite linhas para outra função. Como a mágica precisa ser uma coisa só, então eu preciso de uma função que retorne a função, e que mantenha dentro dela o resíduo entre linhas. Algo assim:

function splitLines() {
    let buff = "";
    const f = (data) => {
        buff += data;
        const parts = buff.split("\n")

        for (const atom of parts.slice(0, -1)) {
            console.log(atom)
        }
        buff = parts[parts.length - 1];
    }
    return f;
}

Aqui, eu primeiro junto o resíduo da rodada anterior (começa com resíduo vazio) com a entrada, então eu separo as linhas e envio todas as linhas completas (parts.slice(0, -1)). A última parte é o resíduo, então após enviar as linhas eu atualizo o resíduo e fico pronto para receber mais dados.

Agora, eu preciso indicar o que vai acontecer com essas linhas, como se fossem “eventos”. Por isso sinalizei com o .on(). Vamos usar o esquema de adicionar atributos/métodos em funções? Estilo o que foi mostrado em Recursão a moda clássica em TS: auto referência do tipo de função e em Funções como padrões de projeto: do GoF pro Computaria:

function splitLines() {
    let buff = "";
    const f = (data) => {
        buff += data;
        const parts = buff.split("\n")

        for (const atom of parts.slice(0, -1)) {
            console.log(atom)
        }
        buff = parts[parts.length - 1];
    }
    f.on = (action) => {
        // registra a ação
        return f;
    }
    return f;
}

Nota que o .on retorna a própria função, visto que o retorno dele que vai ser usado para o process.stdin.on('data', magica.on(...)).

Ok, agora eu preciso ligar a ação passada com o laço. E… bem, por que não manter as ações anteriores? Isso pode facilitar minha vida (inclusive me ajudou a debugar a geração de primos (eu tinha esquecido de mudar o estado após a primeira leitura)). E qual seria a ação neutra para poder juntar? A noop: (linha) => {}. E agora para juntar? Eu posso executar a função anterior e depois a função nova:

let action = (linha) => {}

//...

const addAction = (newAction) => {
    const oldAction = action;
    action = (linha) => {
        oldAction(linha);
        newAction(linha);
    }
}

addAction(console.log)
addAction(linha => console.error(`recebi como entrada: >>>${linha}<<<`))

Juntando tudo isso:

// solveProblemLinePerLine definido

function splitLines() {
    let buff = "";
    let _action = (el) => {};
    const f = (data) => {
        buff += data;
        const parts = buff.split("\n")

        for (const atom of parts.slice(0, -1)) {
            _action(atom)
        }
        buff = parts[parts.length - 1];
    }
    f.on = (action) => {
        const oldAction = _action;
        _action = (el) => {
            oldAction(el);
            action(el);
        };
        return f;
    }
    return f;
}

process.stdin.on('data', splitLines().on(solveProblemLinePerLine))

Exemplo do gerador de primos

O código completo fica assim:

let state = "INIT"
let nProblems = 0

function readNProblems(n) {
    nProblems = n
}

function isPrime(p) {
    if (p <= 1) {
        return false;
    }
    if (p == 2) {
        return true;
    }
    if (p % 2 == 0) {
        return false;
    }
    for (let i = 3; i * i <= p; i += 2) {
        if (p % i == 0) {
            return false;
        }
    }
    return true;
}

function readInstance(menor, maior) {
    for (let i = menor; i <= maior; i++) {
        if (isPrime(i)) {
            console.log(i);
        }
    }
}

function solveProblemLinePerLine(line) {
    switch (state) {
        case "INIT":
            readNProblems(Number(line));
            state = "INSTANCE";
            break;
        case "INSTANCE":
            const s = line.split(" ")
            readInstance(Number(s[0]), Number(s[1]));
            console.log();
            nProblems--;
            if (nProblems == 0) {
                state = "END";
                process.exit(0)
            }
            break;
    }
}

// boilerplate abaixo!!

function splitLines() {
    let buff = "";
    let _action = (el) => {};
    const f = (data) => {
        buff += data;
        const parts = buff.split("\n")

        for (const atom of parts.slice(0, -1)) {
            _action(atom)
        }
        buff = parts[parts.length - 1];
    }
    f.on = (action) => {
        const oldAction = _action;
        _action = (el) => {
            oldAction(el);
            action(el);
        };
        return f;
    }
    return f;
}

process.stdin.on('data', splitLines().on(solveProblemLinePerLine))

Durante a execução, note que o programa para (devido ao process.exit(0)) quando é informado os casos de teste. Isso favorece o teste manual, ao executar o código, ele para no momento que se espera.

Exemplo da vida, o universo e tudo mais

Aqui, o código executa eternamente até o fim da entrada, por mais que chegue o 42 em algum momento:

let state = "GO";
function solveProblemLinePerLine(line) {
    if (line == "42") {
        state = "STOP";
    }
    if (state == "STOP") {
        return;
    }
    console.log(line);
}

// boilerplate abaixo!!

function splitLines() {
    let buff = "";
    let _action = (el) => {};
    const f = (data) => {
        buff += data;
        const parts = buff.split("\n")

        for (const atom of parts.slice(0, -1)) {
            _action(atom)
        }
        buff = parts[parts.length - 1];
    }
    f.on = (action) => {
        const oldAction = _action;
        _action = (el) => {
            oldAction(el);
            action(el);
        };
        return f;
    }
    return f;
}

process.stdin.on('data', splitLines().on(solveProblemLinePerLine))

Usando o template: macaco prego

Bem, para usar o template, precisamos entender como ele funciona. Basicamente, para usar corretamente o modelo, precisamos pensar na máquina de estados e em como ela vai reagir às entradas.

Como motor de exemplo, vamos pegar a questão Macaco Prego. Basicamente aqui a entrada vai se dividir em dois blocos:

primeira linha: N, a quantidade de quadrados
próximas N linhas: descrições de quadrados

tl;dr da questão: ele precisa da interseção de todos os quadrados. Se não houver, imprimir nenhum. Os quadrados são definidos por quatro números: LEFT, TOP, RIGHT, BOTTOM.

Ah, o N pode ser 0 para indicar saída (na saída não se imprime nada).

Para cada caso de teste, a impressão deve ser Teste X, onde X é o número do teste sendo executado (começa do 1), seguido da interseção (ou nenhum) e seguido de uma linha em branco.

Bem, vamos analisar como resolver?

Basicamente, temos o estado INIT. Quando recebe 0, vamos para o estado de END. Caso contrário, vamos para as leituras. Aqui, a primeira leitura vou tratar como especial, pois precisamos da interseção e a interseção de todos os retângulos sempre vai ser uma parte do retângulo inicial. Então, vamos para o estado READ_0. Após essa leitura, contamos N-1 vezes a leitura no estado READ, após isso imprimimos a resposta e voltamos para o estado INIT.

Isso já deve dar um bom esqueleto para o solveProblemLinePerLine:

let state = "INIT";
let testNumber = 1;

function solveProblemLinePerLine(line) {
    switch (state) {
        case "INIT":
            leQuantidade(Number(line));
            if (quantidadeRestante == 0) {
                state = "END";
                process.exit(0);
            } else {
                state = "READ_0";
            }
            break;
        case "READ_0": {
            const [left, top, right, bottom] = line.split(" ");
            leituraZero(Number(left), Number(top), Number(right), Number(bottom));
            quantidadeRestante--;
            state = "READ";
            break;
        }
        case "READ": {
            const [left, top, right, bottom] = line.split(" ");
            leituraInc(Number(left), Number(top), Number(right), Number(bottom));
            quantidadeRestante--;
            if (quantidadeRestante == 0) {
                imprimeResposta(testNumber);
                testNumber++;
                state = "INIT";
            }
            break;
        }
        case "END":
            process.exit(0);
            break;
    }
}

Vamos preencher as lacunas? Começar por leituraZero. Aqui, a melhor solução é preencher um objeto chamado intersec com o valor left, top, right, bottom, sem segredo:

let intersec = {};

function leituraZero(left, top, right, bottom) {
    intersec = { left, top, right, bottom }
}

Bem tranquilo, né? Bem, agora vamos na leitura incremental. Aqui, ao descobrir que a interseção é impossível, eu posso simplesmente sobrescrever o objeto intersec com o valor nenhum. Agora posso fazer uma tratativa especial para esse valor. De resto, se a nova esquerda estiver mais pra lá do que a velha esquerda, escolhe a nova. Vai ter uma tratativa dessas para cada um:

function leituraInc(left, top, right, bottom) {
    if (intersec == "nenhum") {
        // caso especial, precisa fazer nada
        return;
    }
    const leftR = Math.max(left, intersec.left);
    const topR = Math.min(top, intersec.top);
    const rightR = Math.min(right, intersec.right);
    const bottomR = Math.max(bottom, intersec.bottom);

    intersec = {
        left: leftR,
        top: topR,
        right: rightR,
        bottom: bottomR
    };
}

É isso? Bem, não, preciso validar antes se a interseção existe. Em que caso a interseção pode não existir? No caso em que a esquerda está depois da direita, ou que o topo está debaixo do fundo:

function leituraInc(left, top, right, bottom) {
    if (intersec == "nenhum") {
        // caso especial, precisa fazer nada
        return;
    }
    const leftR = Math.max(left, intersec.left);
    const topR = Math.min(top, intersec.top);
    const rightR = Math.min(right, intersec.right);
    const bottomR = Math.max(bottom, intersec.bottom);

    if (leftR > rightR || topR < bottomR) {
        intersec = "nenhum";
        return;
    }

    intersec = {
        left: leftR,
        top: topR,
        right: rightR,
        bottom: bottomR
    };
}

Finalmente, a impressão. Se for nenhum, só imprime o nenhum e seja feliz. Caso contrário, precisa imprimir left, top, right, bottom nessa ordem separado por espaços. E então uma linha em branco a mais:

function imprimeResposta() {
    console.log(`Teste ${testNumber}`);
    if (intersec == "nenhum") {
        console.log(intersec);
    } else {
        const { left, top, right, bottom } = intersec;
        console.log(`${left} ${top} ${right} ${bottom}`)
    }
    console.log();
}

É isso? Bem, na real esqueci de um caso. Se for informada apenas uma única área, a resposta vai ser exatamente a entrada, já que a interseção de todos os retângulos, quando tem somente um único retângulo, é ele mesmo. Posso lidar com isso como caso especial? Posso. Posso lidar com isso no READ_0? Posso.

Me parece mais trivial criar um caso especial: READ_UNICO!

function solveProblemLinePerLine(line) {
    switch (state) {
        case "INIT":
            leQuantidade(Number(line));
            if (quantidadeRestante == 0) {
                state = "END";
                process.exit(0);
            } else if (quantidadeRestante == 1) {
                state = "READ_UNICO";
            } else {
                state = "READ_0";
            }
            break;
        case "READ_UNICO": {
            const [left, top, right, bottom] = line.split(" ");
            leituraZero(Number(left), Number(top), Number(right), Number(bottom));
            imprimeResposta(testNumber);
            testNumber++;
            state = "INIT";
            break;
        }
        case "READ_0": {
            const [left, top, right, bottom] = line.split(" ");
            leituraZero(Number(left), Number(top), Number(right), Number(bottom));
            quantidadeRestante--;
            state = "READ";
            break;
        }
        case "READ": {
            const [left, top, right, bottom] = line.split(" ");
            leituraInc(Number(left), Number(top), Number(right), Number(bottom));
            quantidadeRestante--;
            if (quantidadeRestante == 0) {
                imprimeResposta(testNumber);
                testNumber++;
                state = "INIT";
            }
            break;
        }
        case "END":
            process.exit(0);
            break;
    }
}

Juntando tudo:

let state = "INIT";
let testNumber = 1;
let intersec = {};
let quantidadeRestante = 0;

function leQuantidade(quantidade) {
    quantidadeRestante = quantidade;
}

function leituraZero(left, top, right, bottom) {
    intersec = { left, top, right, bottom }
}

function leituraInc(left, top, right, bottom) {
    if (intersec == "nenhum") {
        // caso especial, precisa fazer nada
        return;
    }
    const leftR = Math.max(left, intersec.left);
    const topR = Math.min(top, intersec.top);
    const rightR = Math.min(right, intersec.right);
    const bottomR = Math.max(bottom, intersec.bottom);

    if (leftR > rightR || topR < bottomR) {
        intersec = "nenhum";
        return;
    }

    intersec = {
        left: leftR,
        top: topR,
        right: rightR,
        bottom: bottomR
    };
}

function imprimeResposta() {
    console.log(`Teste ${testNumber}`);
    if (intersec == "nenhum") {
        console.log(intersec);
    } else {
        const { left, top, right, bottom } = intersec;
        console.log(`${left} ${top} ${right} ${bottom}`)
    }
    console.log();
}

function solveProblemLinePerLine(line) {
    switch (state) {
        case "INIT":
            leQuantidade(Number(line));
            if (quantidadeRestante == 0) {
                state = "END";
                process.exit(0);
            } else if (quantidadeRestante == 1) {
                state = "READ_UNICO";
            } else {
                state = "READ_0";
            }
            break;
        case "READ_UNICO": {
            const [left, top, right, bottom] = line.split(" ");
            leituraZero(Number(left), Number(top), Number(right), Number(bottom));
            imprimeResposta(testNumber);
            testNumber++;
            state = "INIT";
            break;
        }
        case "READ_0": {
            const [left, top, right, bottom] = line.split(" ");
            leituraZero(Number(left), Number(top), Number(right), Number(bottom));
            quantidadeRestante--;
            state = "READ";
            break;
        }
        case "READ": {
            const [left, top, right, bottom] = line.split(" ");
            leituraInc(Number(left), Number(top), Number(right), Number(bottom));
            quantidadeRestante--;
            if (quantidadeRestante == 0) {
                imprimeResposta(testNumber);
                testNumber++;
                state = "INIT";
            }
            break;
        }
        case "END":
            process.exit(0);
            break;
    }
}

// boilerplate abaixo!!

function splitLines() {
    let buff = "";
    let _action = (el) => {};
    const f = (data) => {
        buff += data;
        const parts = buff.split("\n")

        for (const atom of parts.slice(0, -1)) {
            _action(atom)
        }
        buff = parts[parts.length - 1];
    }
    f.on = (action) => {
        const oldAction = _action;
        _action = (el) => {
            oldAction(el);
            action(el);
        };
        return f;
    }
    return f;
}

process.stdin.on('data', splitLines().on(solveProblemLinePerLine))

E… voi là! Estamos prontos! Vamos submeter!

E claro que agora eu descubro que o Spoj não aceita Node para essa questão em específico! Triste…

Mas, sabe o que ele aceita? SpiderMonkey JS! Vamos lá!

Quais são as transformações a serem feitas? Bem, para começar, não temos a leitura daquele jeito. A leitura da linha é uma função chamada readline() que devolve uma linha lida (ou null se chegar no final da stream, o que não acontece aqui porque para sair se informa 0).

Além disso, o console.log é substituído por print. E finalmente não tem o process.exit(0). No lugar, vou coloar um loop de leitura infinita até o estado ser END, aí para a execução:

let state = "INIT";
let testNumber = 1;
let intersec = {};
let quantidadeRestante = 0;

function leQuantidade(quantidade) {
    quantidadeRestante = quantidade;
}

function leituraZero(left, top, right, bottom) {
    intersec = { left, top, right, bottom }
}

function leituraInc(left, top, right, bottom) {
    if (intersec == "nenhum") {
        // caso especial, precisa fazer nada
        return;
    }
    const leftR = Math.max(left, intersec.left);
    const topR = Math.min(top, intersec.top);
    const rightR = Math.min(right, intersec.right);
    const bottomR = Math.max(bottom, intersec.bottom);

    if (leftR > rightR || topR < bottomR) {
        intersec = "nenhum";
        return;
    }

    intersec = {
        left: leftR,
        top: topR,
        right: rightR,
        bottom: bottomR
    };
}

function imprimeResposta() {
    print(`Teste ${testNumber}`);
    if (intersec == "nenhum") {
        print(intersec);
    } else {
        const { left, top, right, bottom } = intersec;
        print(`${left} ${top} ${right} ${bottom}`)
    }
    print();
}

function solveProblemLinePerLine(line) {
    switch (state) {
        case "INIT":
            leQuantidade(Number(line));
            if (quantidadeRestante == 0) {
                state = "END";
                return;
            } else if (quantidadeRestante == 1) {
                state = "READ_UNICO";
            } else {
                state = "READ_0";
            }
            break;
        case "READ_UNICO": {
            const [left, top, right, bottom] = line.split(" ");
            leituraZero(Number(left), Number(top), Number(right), Number(bottom));
            imprimeResposta(testNumber);
            testNumber++;
            state = "INIT";
            break;
        }
        case "READ_0": {
            const [left, top, right, bottom] = line.split(" ");
            leituraZero(Number(left), Number(top), Number(right), Number(bottom));
            quantidadeRestante--;
            state = "READ";
            break;
        }
        case "READ": {
            const [left, top, right, bottom] = line.split(" ");
            leituraInc(Number(left), Number(top), Number(right), Number(bottom));
            quantidadeRestante--;
            if (quantidadeRestante == 0) {
                imprimeResposta(testNumber);
                testNumber++;
                state = "INIT";
            }
            break;
        }
        case "END":
            break;
    }
}

// boilerplate abaixo!!

while (state != "END") {
    const linha = readline();
    solveProblemLinePerLine(linha);
}

Beleza, aparentemente agora lembra o que o SpiderMonkey aceita. Agora, que tal antes validar? Felizmente descobri um sandbox online para experimentar: https://mozilla-spidermonkey.github.io/sm-wasi-demo/.

Mas, bem, roda no browser, né? Não aceita bem o readline, como comportar? Ora, ora, ora… lembra ainda antes de implementar o loop em cima do process.stdin.on('data', ...)? Que testamos passando as strings linha a linha para a função solveProblemLinePerLine? Façamos isso! No lugar do loop de leitura do boilerplate:

const linhas = [
    "3",
    "0 6 8 1",
    "1 5 6 3",
    "2 4 9 0",
    "3",
    "0 4 4 0",
    "3 1 7 -3",
    "6 4 10 0",
    "0"
]

for (const linha of linhas) {
    //const linha = readline();
    solveProblemLinePerLine(linha);
}

Só como teste de sanidade mesmo, e funcionou. Vamos submeter?

Bem, a submissão foi com suceso. O boilerplate funciona, e adaptar ele para SpiderMonkey também deu certo.

Nota sobre leitura de dados vs programação competitiva

Particularmente eu estou bem mais acostumado com ter domínio do fluxo do programa quando estou em uma questão de programação competitiva. No lugar de definir uma máquina de estados manualmente, eu simplesmente deixo o código fazer isso diretamente. Por exemplo, seria muito mais natural fazer assim:

function calculaIntersec(intersec, left, top, right, bottom) {
    if (intersec == "nenhum") {
        // caso especial, precisa fazer nada
        return "nenhum";
    }
    const leftR = Math.max(left, intersec.left);
    const topR = Math.min(top, intersec.top);
    const rightR = Math.min(right, intersec.right);
    const bottomR = Math.max(bottom, intersec.bottom);

    if (leftR > rightR || topR < bottomR) {
        return "nenhum";
    }

    return {
        left: leftR,
        top: topR,
        right: rightR,
        bottom: bottomR
    };
}

function resolveProblema(quantidadeRestante) {
    let intersec;
    let [left, top, right, bottom] = readline().split(" ");
    intersec = { left, top, right, bottom };
    quantidadeRestante--;

    while (quantidadeRestante > 0) {
        [left, top, right, bottom] = readline().split(" ");

        intersec = calculaIntersec(intersec, left, top, right, bottom);
        quantidadeRestante--;
    }
    return intersec;
}

function imprimeResposta(intersec, testNumber) {
    print(`Teste ${testNumber}`);
    if (intersec == "nenhum") {
        print(intersec);
    } else {
        const { left, top, right, bottom } = intersec;
        print(`${left} ${top} ${right} ${bottom}`)
    }
    print();
}

let testNumber = 1;
while (true) {
    const quantidadeRestante = Number(readline())
    if (quantidadeRestante == 0) {
        break;
    }
    const intersec = resolveProblema(quantidadeRestante);
    imprimeResposta(intersec, testNumber);
    testNumber++;
}

Aqui tá muito mais direto, a “máquina de estados” agora é o while (true) no programa, tenho muito mais controle da submissão, consigo controlar muito melhor como eu faço a leitura. Mas, bem, o ponto era mostrar o boilerplate em Node, e isso foi demonstrado que funciona. E que é possível adaptar para rodar com SpiderMonkey em cima da mesma mentalidade.

Rodando o gitlab runner em um docker-in-docker

Tue, 10 Feb 2026 00:00:00 +0000

Estou fazendo um curso com foco em DevOps, e nesse curso foi necessário fazer uma pipeline de uma aplicação. Estava indo tudo bem, estava rodando diversas vezes os meus jobs nos GitLab Runners da instância GitLab.com.

Mas eu recebi o seguintes alerta:

E ainda nem estava na metade concluída do trabalho… Portanto, eu precisava de uma alternativa! E aqui entra o cadastro do runner do GitLab!

O que é o GitLab Runner

No GitLab, você define o seu próprio fluxo de CI. Basicamente ele é uma pipeline dividida em stages, sendo que cada stage é um agrupamento arbitrário com valor semântico.

Dentro de uma stage encontramos vários jobs. E é no job que determinamos que algo será executado! Por exemplo, no post Quebrei o CSS com a publicação anterior, e agora?, foi criado o job alpine-test para que eu pudesse validar se era possível retornar a funcionar a construção do Computaria usando como base uma imagem alpine. E era um Runner quem iria pegar a descrição desse job e rodar!

Entra o DIND

Devido a uma decisão arquitetural minha, não quero rodar o Runner diretamente em cima do dockerd da minha máquina, mas sim dentro de um ambiente Docker mais isolado: rodando o Docker no Docker. Em inglês, Docker in Docker, que dá origem à nomenclatura DIND: Docker-IN-Docker.

Para rodar o DIND, você precisa executar o docker com privilégios. E, para rodar os comandos no meu DIND, eu não posso rodar diretamente com o comando docker. Se eu rodar docker run ..., ele será executado no meu dockerd, não no dockerd do DIND. Então, tenho duas alternativas para isso:

rodar um comando docker que roda um comendo docker no DIND
expor a porta do DIND e, ao executar o comando docker localmente, garantir que a variável de ambiente DOCKER_HOST aponta para o DIND

Vamos ver aqui como que faz? Bem, tem algumas maneiras para expor o dockerd para o comando docker. As principais que eu conheço são:

através de um socket unix
através de uma conexão TCP segura (por padrão porta 2376)
através de uma conexão TCP INsegura (por padrão porta 2375)

Quando você roda o dind, a priori ele tenta expor uma conexão segura, mas você consegue sobrescrever esse comportamento colocando a variável de ambiente DOCKER_TLS_CERTDIR com uma string vazia. Assim, podemos subir o dind dessa maneira:

docker run \
    --rm \
    -d \
    --name="dind-test" \
    -e "DOCKER_TLS_CERTDIR=" \
    -p 2375:2375 \
    --privileged \
    docker:29-dind

Explicando cada ponto:

docker run estou pedindo para rodar algo via Docker
--rm o container será removido quando ele parar, não ocupando espaço a toa
--name="dind-test" criei um nome para o container para facilitar trabalhar com ele
-e "DOCKER_TLS_CERTDIR=" criando uma variável de ambiente chamada DOCKER_TLS_CERTDIR com conteúdo vazio
-p 2375:2375 estou expondo a porta 2375, então bater em localhost:2375 é encaminhado para esse container especificamente
--privileged para rodar o DIND preciso de permissões com privilégio
docker:29-dind a imagem que estou usando

Dado isso, agora eu posso executar diretamente comandos docker nele, pois estou expondo ele a conexões TCP:

DOCKER_HOST=tcp://localhost:2375 docker images

Ele retorna que agora não tem nenhuma imagem. De fato, é a primeira vez que rodamos algo nele, não tem nada o que fazer. Podemos também executar algo nele via docker exec:

docker exec -it dind-test docker images

Basicamente após falar que se deseja executar no container dind-test o comando docker images. Podemos entrar na máquina também, na shell dela:

docker exec -it dind-test sh

E aqui podemos também pedir para ele executar os comandos adequados. Aqui é um ambiente de shell, podemos rodar qualquer comando disponível de modo interativo (inclusive o vi, que vem instalado por padrão).

Quando executamos diretamente no container, o comando docker segue o padrão de tentar falar com um socket unix, já que localmente não tem definida a variável DOCKER_HOST.

Caso você seja aventureiro (e eu precisei ser um dado momento do passado), você ainda pode sobrescrever o comportamento padrão de entrada da imagem alterando o ENTRYPOINT. Não precisa gerar uma imagem nova para isso, existe a opção de alterar com a opção --entrypoint. Aqui, você informa como que o container vai se iniciar, então o padrão de que a variável de ambiente DOCKER_TLS_CERTDIR vazia não existe mais.

E por que alguém iria precisar fazer isso? Bem, tem algumas configurações que são do próprio dockerd, e eu não encontrei maneira trivial de fazer elas rodarem usando o entrypoint padrão do container. Por exemplo, posso configurar para pegar de um registy próprio que usa conexão HTTP, com --insecure-registry registry:5000, e assim eu posso também subir o meu próprio docker-registry localmente e publicar imagens localmente.

Encapsulando no compose.yaml

No meu caso, não é de meu interesse compartilhar o meu DIND com o ambiente externo. Apenas manter ele para rodar os runners em cima. E no caso eu tenho também o interesse de rodar um comando mais complexo dentro do próprio DIND! Eu também tenho interesse de compartilhar um diretório do gitlab runner com o meu DIND para efeito de persistência. E, para ficar mais longevo que apenas o próprio DIND, compartilhar esse diretório de persistência com o mundo externo.

E assim, já que eu já vou compartilhar um diretório com o mundo externo, vou colocar logo o meu script complexo dentro desse diretório. No caso, escolhi um diretório chamado runner. Ele vai ter o script que faz a “magia” e, após o registro do runner na instância do GitLab, mandar rodar a “magia” novamente deixa o runner rodando feliz aceitando jobs.

services:
  dind:
    image: "docker:29-dind"
    container_name: pipeline_dind
    privileged: true
    volumes:
      - ./runner:/runner

E dentro dessa máquina, pipeline_dind, eu tenho a “magia”. No caso, escolhi pela simplicidade uma interação bem simples:

se não tiver o arquivo de configuração, faz o registro do gitlab runner
se já tiver o arquivo de configuração, rodar em daemon o gitlab runner

#!/bin/sh

if [ -f /runner/config.toml ]; then
    docker run --privileged --rm -d -v /runner:/etc/gitlab-runner/ -v /var/run/docker.sock:/var/run/docker.sock gitlab/gitlab-runner run
else
    docker run --privileged --rm -ti -v /runner:/etc/gitlab-runner/ -v /var/run/docker.sock:/var/run/docker.sock gitlab/gitlab-runner register
    sed -i 's/privileged = false/privileged = true/' /runner/config.toml
fi

Aqui eu estou compartilhando 2 coisas fundamentais com o gitlab-runner:

o diretório runner, que é onde vou salvar tanto o meu script de magia como o arquivo de configuração (poderia ser separado)
o socket unix do dockerd

Após fazer o cadastro, em que informo o token, a URL da instância do gitlab, e que o meu runner é do tipo docker, eu altero uma linha no toml: como eu necessito rodar dind dentro do meu runner, eu preciso que o gitlab runner, quando for subir algumas imagens docker, as suba com privilégios:

sed -i 's/privileged = false/privileged = true/' /runner/config.toml

Então faço essa substituição inline. Isso é para o meu caso em que eu rodo um dind como serviço no .gitlab-ci.yaml, nem sempre isso é estritamente necessário. O compose.toml fica exposto para se poder alterar, então é fácil alterar ele manualmente (se você souber o que está fazendo, claro), e os runners sabem como se recuperar após uma alteração no arquivo de configuração. Podemos dizer que eles fazem um “self redeploy” automático e confiável a cada alteração.

Na primeira vez que se executa a magia, o container é executado de modo interativo: docker run -it [...]. Tomei essa escolha para que o usuário (no caso, eu normalmente) pudesse customizar. Na segunda vez que roda a magia, já vai ter o arquivo no lugar, então manda executar sem maiores encrencas o gitlab runner como um daemon.

Para glorificar a preguiça obviamente eu criei um script só para executar a magia dentro do DIND: run-magic-in-dind.sh:

#!/bin/sh

docker exec -it pipeline_dind /runner/magic.sh

Desafios não previstos

Devido a natureza o curso, um dos requisitos era rodar o trivy para buscar vulnerabilidades conhecidas. Encontrei uns templates pronto para isso, indicado pelo próprio site do trivy como parte do ecossistema:

Esses templates do SecObserve fazem tanto a análise do código estático, de suas dependências, quanto também da imagem. Para configurar esses jobs, usei o próprio esquema de templates do gitlab-ci:

include:
  - "https://raw.githubusercontent.com/SecObserve/secobserve_actions_templates/main/templates/SCA/trivy_filesystem.yml"
  - "https://raw.githubusercontent.com/SecObserve/secobserve_actions_templates/main/templates/SCA/trivy_image.yml"

Eu tinha a necessidade de salvar o registro da análise em uma pasta específica, então precisei garantir a existência dela via before_script. Além disso, o gitlab-ci agora permite que você suba o resultado específico da busca de vulnerabilidades usando [job].artifacts.report.sast. Ficou assim o job do trivy_filesystem:

trivy_filesystem:
  extends: .trivy_filesystem
  stage: security
  before_script:
    - mkdir -p reports/
  variables:
    TARGET: "package-lock.json"
    REPORT_NAME: "reports/trivy_npm.json"
    SO_UPLOAD: false
  artifacts:
    reports:
      sast: "reports/trivy_npm.json"
    paths: [ "reports/trivy_npm.json" ]
  needs: []
  rules:
    - if: $CI_PIPELINE_SOURCE != "pipeline"

O SO_UPLOAD deve ser marcado como true (padrão do template) se você estiver ativamente usando os serviços do SecObserve.

Isso funcionou bem. Mas a análise automática da vulnerabilidade cadastrada via gitlab-ci no merge request não está ativa para plano free. Então, após rodar as análises, criei um outro job que simplesmente coleta as informações e procura por falhas high (score 7.0) ou superior. Basicamente, uma chamada a um arquivo JS:

vuln-scan:
  image: node:25-alpine3.23
  needs: [ "trivy_filesystem", "trivy_image" ]
  stage: security
  variables:
    CSV_LIST_REPORTS_JSON: reports/trivy_npm.json,reports/trivy_image.json
  script:
    - node infra/vuln/check_vuln.js ${CSV_LIST_REPORTS_JSON}
  rules:
    - if: $CI_PIPELINE_SOURCE != "pipeline"

E aqui o script que checa as vulnerabilidades:

if (process.argv.length < 3) {
    console.log("No JSON passed as args")
    process.exit(0)
}

const accHighV = [];

for (const vulnFile of process.argv.slice(2).flatMap(csv => csv.split(',')).map(path => "../../" + path)) {
    const sast = require(vulnFile);

    const highV = sast.vulnerabilities.flatMap(vuln => vuln.ratings.map(r => [vuln,r])).filter(([v, rating]) => rating.score >= 7)


    highV.map(([v,r]) => ({
        id:v.id, 
        recommendation:v.recommendation,
        description: v.description
    }))
    accHighV.push(...highV)
}

if (accHighV.length > 0) {
    process.exitCode = 1;
    console.error("Some high stakes vulnerabilities were found")
    accHighV.forEach(([vuln, rating]) => {
        let msg = `id: ${vuln.id} ${rating.severity} (${rating.score})

description: ${vuln.description}

recommendation? ${vuln.recommendation ?? "no recommendation =/"}
---
`;
        console.error(msg)
    })
}

E tudo estava funcionando maravilhosamente bem! Nos runners do gitlab.com! Porém… meus minutos acabaram, e com isso precisei rodar esse job localmente. Só que…

Pulling docker image ghcr.io/secobserve/secobserve-scanners:2026_01 ...
WARNING: Failed to pull image with policy "always": Error response from daemon: no matching manifest for linux/arm64/v8 in the manifest list entries: no match for platform in manifest: not found (manager.go:237:0s)
ERROR: Job failed: failed to pull image "ghcr.io/secobserve/secobserve-scanners:2026_01" with specified policies [always]: Error response from daemon: no matching manifest for linux/arm64/v8 in the manifest list entries: no match for platform in manifest: not found (manager.go:237:0s)

E, bem, precisava rodar a análise, né? Então, como contornar?

Por incrível que pareça é mais tranquilo do que eu pensei que seria! Basta pedir para o gitlab-ci puxar uma imagem docker para uma plataforma específica. Se ele não tinha o linux/arm64/v8, que tal rodar o job na mesma plataforma que eram os runners compartilhados da instância? linux/amd64?

Para isso, precisei indicar na imagem que, ao subir com o docker, precisa estar adequada a plataforma:

trivy_filesystem:
  extends: .trivy_filesystem
  image:
    name: ghcr.io/secobserve/secobserve-scanners:2026_01
    docker:
      platform: linux/amd64
  # ... o resto segue igual

Há relatos (bem factíveis, por sinal) de que usar uma plataforma que não seja aquela em que o DIND está rodando ocasionava em uma execução bem mais lenta. Mas isso é só um scan de vulnerabilidades, eu aceito aumentar o tempo de execução de quase instantânea para alguns segundos.

E… bem, se isso estava acontecendo com o build de terceiros, o que fazer com o meu build? Com a minha? Vamos fazer multiplataforma!

Basicamente, para conseguir fazer o build usando como target múltiplas plataformas, segui alguns tutoriais para chegar nesse ponto:

first-docker-image:
  needs:
    - "unit-test-job"
  image: docker:24.0.5-cli
  services:
    - name: docker:24.0.5-dind
      alias: docker
  stage: create-image
  variables:
    IMAGE_TAG_NAME: $CI_REGISTRY_IMAGE:temp-$CI_COMMIT_SHORT_SHA
    PLATFORMS: linux/amd64,linux/arm64/v8
  before_script:
    - echo "$CI_REGISTRY_PASSWORD" | docker login $CI_REGISTRY -u $CI_REGISTRY_USER --password-stdin
  script:
    - touch .env
    - docker buildx create --use
    - docker buildx build --platform "$PLATFORMS" . -t "$IMAGE_TAG_NAME" --push
  rules:
    - if: $CI_PIPELINE_SOURCE != "pipeline"

O comando docker build --platform [PLATFORM] ... não aceitou usar como target múltiplas plataformas alvo, então de fato precisei usar o docker buildx build. Além disso, eu também não consegui enviar diretamente via um simples docker push. Para gerenciar isso da maneira correta, adiciona-se a flag --push no final do comando docker buildx build.

Além da opção de SAST, através do gitlab-ci podemos apontar para a cobertura de código nos testes e também para testes unitários:

unit-test-job:
  image: node:25-alpine3.23
  stage: test
  before_script:
    - npm ci
  script:
    - npm test -- --coverage --coverageDirectory=coverage
  artifacts:
    paths:
      - coverage/
      - reports/
    when: always
    reports:
      coverage_report:
        coverage_format: cobertura
        path: coverage/cobertura-coverage.xml
      junit: reports/*.xml
  cache:
    key: unit-test-job
    paths:
      - node_modules/

Uma das formas de saída da análise dos testes fica dentro de reports. No caso específico, o JEST (ferramenta de teste para node usada no projeto) estava configurado para emitir umas coisas bem interessantes:

/** @type {import('jest').Config} */
const config = {
  verbose: true,
  collectCoverage: true,
  collectCoverageFrom: [
    'src/**/*.js',
    '!**/node_modules/**',
    '!**/vendor/**',
  ],
  coverageReporters: ["clover", "json", "json-summary", "lcov", "text", "cobertura"],
  reporters: [
    "default",
    ["jest-junit", {outputDirectory: 'reports', outputName: 'report.xml'}]
  ]
};

module.exports = config;

Para indicar para o gitlab-ci onde estará o resultado, usei de [job].artifacts.junit. E além desse do teste junit, tem também a cobertura, que já na versão gratuita o GitLab exibe no merge request quais linhas foram cobertas e quais não foram:

Para esse tipo de relatório, precisei fazer com que o relatório de cobertura do JEST fosse do tipo cobertura, já que esse tipo de cobertura o gitlab-ci aceita.

Blog full throttle!!

Uma coisa que me incomodava a bastante tempo na hora de rodar o build do blog era o tempo de espera fazendo o mesmo trabalho repetitivo. Tudo bem que alguma coisa foi otimizada após as análises de tempo específicas feitas no Quebrei o CSS com a publicação anterior, e agora?.

Mas… e se eu não precisar instalar as dependências do Ruby novamente? E se minha imagem estiver boa o suficiente?

Aqui entra a magia! A imagem full-throttle do blog: blog full throtle docker. Esse projeto tem apenas um objetivo: gerar uma imagem com boa parte das dependências já baixadas.

Agora, como conseguir isso? Instalando as coisas tal qual tem no .gitlab-ci.yaml daqui do blog! Mas para isso seria necessário ter acesso ao Gemfile e ao Gemfile.lock, não é? Também não tem problema, tem uma API do GitLab que faz exatamente isso!

A ideia então:

o job starta manualmente
primeiro baixamos os arquivos desejados, salvando como artefatos
inicia o build docker com base na imagem ruby:3.2-alpine (a imagem usada anteriormente)
instala coisas do sistema (gcc, g++, bundler etc)
copia o Gemfile e o Gemfile.lock
instala as dependências
remove o Gemfile e o Gemfile.lock

Assumindo a existência do Gemfile e do Gemfile.lock, o Dockerfile é muito tranquilo:

FROM ruby:3.2-alpine

WORKDIR /jekyll

ENV BUNDLE_FROZEN=true
RUN apk add gcc g++ make && \
    gem install bundler

COPY Gemfile /jekyll/
COPY Gemfile.lock /jekyll/

RUN bundle install && \
    rm Gemfile Gemfile.lock

O .gitlab-ci.yaml consiste de 3 estágios:

start
fetch dos arquivos
build do Dockerfile

O build do Dockerfile é a parte menos sofisticada:

full-throttle-image:
  stage: create-image
  needs:
  - fetch-gemfile
  image: docker:24.0.5-cli
  services:
  - name: docker:24.0.5-dind
    alias: docker
  before_script:
  - echo "$CI_REGISTRY_PASSWORD" | docker login $CI_REGISTRY -u $CI_REGISTRY_USER --password-stdin
  script:
  - FULL_THROTTLE_IMAGE="$CI_REGISTRY_IMAGE:`date -Idate | tr - .`"
  - docker build . -t "$FULL_THROTTLE_IMAGE"
  - docker push "$FULL_THROTTLE_IMAGE"

As variáveis DOCKER_HOST e DOCKER_TLS_CERTDIR estão registradas globalmente.

A única sofisticação que ele tem é que pega os artefatos do job fetch-gemfile. O job de start, bem, ele foi feito só para ser uma trava manual mesmo:

start-pipeline:
  image: alpine:3.23
  stage: start
  when: manual
  script:
  - echo "Começando a criar a imagem desejada"

O job que faz o fetch dos arquivos, por sua vez, já tem um pouquinho mais de requinte. Eu precisei do ID do blog para poder bater na API corretamente, cadastrei na variável COMPUTARIA_BLOG_PROJECT_ID. Além disso, pela documentação da API de arquivos, o conteúdo do arquivo estará no campo content, só que estará em base64.

Portanto, a solução foi encadear alguns passos:

curl do arquivo desejado
jq para pegar o campo desejado
base64 -d para decodificar o arquivo de volta

E, claro, guardar os arquivos como artefatos:

fetch-gemfile:
  image: alpine:3.23
  stage: fetch-files
  needs:
  - start-pipeline
  before_script:
  - apk add curl jq
  script:
  - >
    curl -s -H "Private-token: $CI_JOB_TOKEN" "${CI_API_V4_URL}/projects/${COMPUTARIA_BLOG_PROJECT_ID}/repository/files/Gemfile?ref=HEAD" -o gemfile-dl.json
  - jq -r ".content" gemfile-dl.json | base64 -d > Gemfile
  - >
    curl -s -H "Private-token: $CI_JOB_TOKEN" "${CI_API_V4_URL}/projects/${COMPUTARIA_BLOG_PROJECT_ID}/repository/files/Gemfile.lock?ref=HEAD" -o gemfile-lock-dl.json
  - jq -r ".content" gemfile-lock-dl.json | base64 -d > Gemfile.lock
  artifacts:
    paths:
    - "Gemfile"
    - "Gemfile.lock"

Eu criei um conjunto de estágios próprios para esse projeto:

stages:
- start
- fetch-files
- create-image

Simplesmente porque achei que esses são os nomes mais semânticos para o que está sendo feito em cada momento.

Usando a imagem

Após fazer o build, eu simplesmente subsituí a imagem base usada no blog:

 default:
-  image: ruby:3.2-alpine
+  image: registry.gitlab.com/computaria/blog-full-throttle-docker:2026.02.10

Nenhuma outra mudança foi feita, inclusive os apk add continuam no lugar, e também o bundle install. Manter esses processos de instalação ajuda a, caso seja necessário mudar algo no container (como instalar, sei lá, jq?), o blog está pronto para se adaptar e reagir, não ficando preso à imagem full-throttle.

E, bem, após o primeiro experimento… o tempo de build caiu de 1min45 para 46s, sendo que após o momento que inicia o script o tempo foi 18s. Simplesmente mágico!

Ajuste no "pequeno espaço" das logos no rodapé do blog

Mon, 02 Feb 2026 00:00:00 +0000

Por um tempo, uma coisa me incomodou MUITO no blog: no rodapé, na lista de redes sociais, alguns logos apareciam com um espaçamento entre o logo da rede específica e o nick, e outras não tinha o espaçamento.

E por muito tempo eu fiquei sem entender o que era isso! Por exemplo:

Note que o logo do Bluesky, do Instagram e do dev.to estão diferentes dos logos do GitLab, GitHub e StackOverflow no print acima.

Esses logos eles foram adicionados aos poucos. Alguns vieram no template (GitLab, GitHub, entre outros), outros foram surgindo aos poucos.

Minha primeira investigação foi em torno de tentar procurar alguma diferença no CSS ou no HTML usado para representar esses elementos visualmente. Não encontrei nada. Foquei nos elementos que foram adicionados principalmente depois do post Usando data files para redes sociais, mas nada chamou a atenção.

Não havia algo diferente na estrutura do HTML, não tinha nenhum seletor CSS que era disparado em alguns casos e outros não. Voltei-me então a o como eu tinha feito a inserção das logos, o que foi imensamente facilitado graças à centralizacão feita no post sobre isso:

<div class="footer-col footer-col-2">
    <ul class="social-media-list">
        {%- assign social_media_shown = site.data.social_media | where_exp: "social_media", "social_media.show != false" -%}
        {% for social_media in social_media_shown -%}
        {%- if social_media.username_literal -%}
        {%- assign username =  social_media.username_literal -%}
        {%- else -%}
        {%- assign username =  site[social_media.username] -%}
        {% endif %}
        <li>{%- include social/icon.html
                        username=username
                        media_base_url=social_media.media_base_url
                        media_url_literal=social_media.media_url_literal
                        media_name=social_media.media_name -%}</li>
        {% endfor %}
    </ul>
</div>

Hmmm, isso nos leva apenas ao preenchimento de variáveis e delega a social/icon.html:

<a href="{%- if include.media_url_literal -%}{{include.media_url_literal}}{%- else -%}{{ include.media_base_url }}/{{ include.username }}{% endif %}"><span class="icon icon--{{include.media_name}}">{% include icon-{{include.media_name}}.svg %}</span><span class="username">{{ include.username }}</span></a>

Basicamente um <a> com dois <span> dentro, o primeiro <span> incluindo o SVG. Nada que chame a atenção…

Então tive a ideia de inspecionar novamente, e dessa vez olhei para o conteúdo exato que estava sendo mostrado, não apenas o HTML mas cada mínimo detalhe que o browser mostrava:

Notou a diferença? Não? Bem, eu também tive bastante dificuldade no começo, mas em um momento de “claridade” finalmente eu percebi: para o íconde do Bluesky (o primeiro mostrado no print), após o </svg> vem um </span>, mas no ícone do StackOverflow há um [whitespace] entre o </svg> e o </span>!

Ok, descobri que realmente havia algo que causava a diferença visual. E, bem, a estrutura que cuidava das inclusões claramente não estava com problemas. Portanto, a diferença deveria estar dentro dos próprios arquivos de SVG!

Vou exemplificar usando o ícone do GitLab e o do Bluesky. Coloquei duas variáveis para representar isso aqui nesse post: gitlabico que gera o ícone sem o espaçamento, e o bskyico que gera com o espaçamento.

Eis o conteúdo delas:

GitLab:

<svg viewBox="0 0 16 16" xmlns="http://www.w3.org/2000/svg" fill-rule="evenodd" clip-rule="evenodd" stroke-linejoin="round" stroke-miterlimit="1.414"><path d="M15.97 9.058l-.895-2.756L13.3.842c-.09-.282-.488-.282-.58 0L10.946 6.3H5.054L3.28.842C3.188.56 2.79.56 2.7.84L.924 6.3.03 9.058c-.082.25.008.526.22.682L8 15.37l7.75-5.63c.212-.156.302-.43.22-.682"/></svg>

Bluesky:

<svg xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 568 501"><title>Bluesky butterfly logo</title><path fill="currentColor" d="M123.121 33.664C188.241 82.553 258.281 181.68 284 234.873c25.719-53.192 95.759-152.32 160.879-201.21C491.866-1.611 568-28.906 568 57.947c0 17.346-9.945 145.713-15.778 166.555-20.275 72.453-94.155 90.933-159.875 79.748C507.222 323.8 536.444 388.56 473.333 453.32c-119.86 122.992-172.272-30.859-185.702-70.281-2.462-7.227-3.614-10.608-3.631-7.733-.017-2.875-1.169.506-3.631 7.733-13.43 39.422-65.842 193.273-185.702 70.281-63.111-64.76-33.89-129.52 80.986-149.071-65.72 11.185-139.6-7.295-159.875-79.748C9.945 203.659 0 75.291 0 57.946 0-28.906 76.135-1.612 123.121 33.664Z"></path></svg>

E aqui um exemplo de como fica a geração do ícone do lado de um texto:

<ul>
<li><span markdown="0" class="icon">{{ gitlabico }}</span><span>Exemplo</span></li>
<li><span markdown="0" class="icon">{{ bskyico }}</span><span>Exemplo</span></li>
</ul>

Exemplo
Exemplo

Veja bem o conteúdo dos arquivos… não tem nenhuma informação no SVG, nos atributos da tag, nada ao redor. Mas tem algo de diferente, bem sutil: o ícone do GitLab termina com uma linha em branco!

Para ilustrar nesse post, criei a variáveis bskyico-ws capturando a expansão do bskyico com uma linha em branco no final:

{%- capture bskyico-ws -%}{{ bskyico }}
{% endcapture %}

Vamos ver se funcionou?

<ul>
<li><span markdown="0" class="icon">{{ gitlabico }}</span><span>Exemplo</span></li>
<li><span markdown="0" class="icon">{{ bskyico-ws }}</span><span>Exemplo</span></li>
<li><span markdown="0" class="icon">{{ bskyico }}</span><span>Exemplo</span></li>
</ul>

Exemplo
Exemplo
Exemplo

Super funcionou! Note que o simples fato de eu ter colocado uma quebra de linha entre a expansão da variável Liquid e o fim do capture foi o suficiente para isso ser devidamente capturado.

E de onde poderia ter vindo esse erro? Bem, veio de minha húbris! Sim, minha mesmo! Eu simplesmente assumi que, ao salvar o SVG no VSCode, ele viria com a quebra de linha! Afinal, é isso que acontece ao se salvar um arquivo via vim: ele adiciona a quebra de linha no final do arquivo se ela não existir. Pois é isso o que diz a convenção de um arquivo de texto bem formatado no Unix. Mas… não é isso o que acontece com o VSCode.

A solução foi adicionar a linha em branco no final de todos os SVGs que não o tinham. Como pode ser visto no commit 465d353e.

Eu simulei apagar a linha em branco e dar um cat no arquivo. No meu terminal, a ausência do \n no final do arquivo é demonstrado por um % com as cores invertidas:

Mas se tiver o \n bonito de final de arquivo, fica assim:

Por sinal, ao abrir o arquivo sem o \n no vim ele reclama que o arquivo não tem, mostranod a tag [noeol]:

Mas ao sair do arquivo com :wq, ele adiciona o \n no final!

Enfim, esse artigo foi só para explorar um pouco mais do processo de descoberta dessa questão do espaçamento que eu não havia documentado.

Caranguejos como computadores completos?

Thu, 29 Jan 2026 00:00:00 +0000

Baseado na thread do Twitter https://twitter.com/JeffQuesado/status/1477843585919770626

O usuário do Twitter @edo9k respondeu uma brincadeira sobre modelos de computação com o seguinte tuíte:

Water based computing considered harmful.
Move your system to crab. https://t.co/c5MF0aBny6
— Eduardo França (@edo9k) December 29, 2021

Em cima do comportamento desses caranguejos, foram feitos 2 portas lógicas. Se quiser se aprofundar mais sobre o que estava sendo discutido, só ler o artigo no ArXiv Robust soldier crab ball gate (ou da versão que foi feito upload para o Wolfram: Robust soldier crab ball gate).

Porta OR

Extraído do Wolfram

Na porta OR, chegam dois sinais de caranguejos e tem um único output. Ela é desenhada de tal forma que, caso tenha pelo menos um sinal chegando, ele saia pelo output; e caso tenha dois sinais chegando, eles se misturam e saem no output. A tabela verdade é a mesma da porta OR tradicional (tome com A e B os dois sinais de input):

A	B	output
0	0	0
1	0	1
0	1	1
1	1	1

Porta AND / NOT a AND b / a AND NOT b

A segunda porta lógica proposta… bem, ela tem 3 saídas:

AND
NOT a AND b
a AND NOT b

Se os caranguejos saírem pelo centro, significa que houve caranguejo em ambos os sinais. Caso saia do lado esquerdo, isso significa que houve apenas o sinal b, portanto ele é algo como b AND NOT a (ou equivalentemente NOT a AND b). E se sair apenas do lado direito, temos a AND NOT b:

A	B	left	center	right
0	0	0	0	0
1	0	0	0	1
0	1	1	0	0
1	1	0	1	0

Porta NOT?

O artigo não traz esquema da porta NOT, apesar de afirmar que a fizeram. Como não deixaram claro no artigo como ela foi desenhada, vou assumir que só tenho as outras duas portas para trabalhar.

Completude funcional

Mas, o que seria essa “completude funcional”? Bem, o ideal seria dizer que é um “sistema computacional capaz de rodar Doom”. Mas, vamos por outras características? A Wikipedia define que a porta NAND tem completude funcional porque toda relação booleana pode ser escrita usando apenas NAND. Então, resumidamente, a “completude funcional” vem quando você consegue expressar todas as operações lógicas, e as operações lógicas “básicas” são:

Toda outra operação booleana você consegue fazer a partir dessas 3 operações. E, como implicado pelo NAND que mencionei anteriormente, você consegue montar essas 3 operações usando apenas NANDs, encadeados de maneira divertida.

Vou considerar aqui apenas operações binárias e unárias. Uma operação que pega 3 inputs e transforma em um único output pode ser interpretado como um encadeamento de 2 operações binárias.

Durante a escrita desse artigo, considere que 1 é TRUE, e que 0 é FALSE. Eu acho mais conveniente em tabelas e quando falo em circuito falar em termos de 0s e 1s, mas para falar das operações lógicas em si eu prefiro deixar explícito em texto corrido TRUE e FALSE.

Isso é apenas uma escolha estilística sem nenhuma implicação maior na leitura do artigo.

Operações unárias

Eu sempre posso obter 2 saídas para cada entrada: TRUE ou FALSE. E para o caso de uma única entrada, só posso ter 2 possíveis inputs: TRUE ou FALSE.

Vamos começar aqui pelo caso básico: eu repito o sinal que vem de entrada:

input	output
0	0
1	1

Temos também a negação, que inverte o sinal:

input	output
0	1
1	0

Mas, para ter totalmente as operações unárias, ainda faltam mais duas… Uma que vai responder TRUE independente da entrada, e outra que vai responder FALSE também independente da entrada. Na prática é como se elas fossem funções constantes, em que o input é ignorado, podendo até mesmo serem elas funções zero-árias.

Para a função que retorna FALSE:

input	output
0	0
1	0

e TRUE:

input	output
0	1
1	1

Operações binárias

As operações básicas já foram apresentadas anteriormente: AND e OR.

AND:

A	B	output
0	0	0
1	0	0
0	1	0
1	1	1

OR:

A	B	output
0	0	0
1	0	1
0	1	1
1	1	1

Podemos também ter as funções triviais de retorno constante, como se fossem zero-árias, como FALSE

A	B	output
0	0	0
1	0	0
0	1	0
1	1	0

e TRUE

A	B	output
0	0	1
1	0	1
0	1	1
1	1	1

Também podemos ter funções que simplesmente retornam um dos inputs. Como A

A	B	output
0	0	0
1	0	1
0	1	0
1	1	1

e B

A	B	output
0	0	0
1	0	0
0	1	1
1	1	1

Já falamos do NAND, né? NAND é o NOT AND, a negação do AND. Só alterar os valores retornados:

A	B	output
0	0	1
1	0	1
0	1	1
1	1	0

Temos também o NOR, que é a simples negação do OR (parecido com o NAND):

A	B	output
0	0	1
1	0	0
0	1	0
1	1	0

De operações clássicas também temos o XOR:

A	B	output
0	0	0
1	0	1
0	1	1
1	1	0

E o EQUIV, ou XNOR já que na prática saber se os dois valores são iguais é negar o XOR:

A	B	output
0	0	1
1	0	0
0	1	0
1	1	1

De operação booleana clássica de livro também tem a implicação, o IMPLY, que retorna FALSE apenas quando a premissa é TRUE e o consequente é FALSE:

A	B	output
0	0	1
1	0	0
0	1	1
1	1	1

Eu poderia continuar até gerar todas as combinações. O que está faltando? Bem, que tal… fazermos uma notação para identificar quem está faltando? Toda entrada vem sempre no mesmo formato:

A	B	output
0	0	w
1	0	x
0	1	y
1	1	z

Ou seja, podemos representar o fluxo INTEIRO da operação lógica como sendo a string de resultados wxyz. O AND nesse caso seria 0001, e o XOR seria a string 0110. Então, aqui temos uma string de booleanos de tamanho 4. Eu posso identificar cada elemento desses booleanos como sendo realmente um bit, e atribuir para cada posição um valor. Lendo isso como sendo uma string em little-endian, o 0001 do AND pode ser lido como o número 8! E portanto o XOR seria 6!

Como temos uma string de binários de tamanho fixo 4, sabemos que temos um total de 16 combinações: que seriam os números de 0 a 15. Vou mapear aqui as operações que já fizemos com seus respectivos valores:

op	string	valor
AND	0001	8
OR	0111	14
FALSE	0000	0
TRUE	1111	15
A	0101	10
B	0011	12
NAND	1110	7
NOR	1000	1
XOR	0110	6
EQUIV	1001	9
IMPLY	1011	13

Hmmm, ordenando pelo valor:

op	string	valor
FALSE	0000	0
NOR	1000	1
XOR	0110	6
NAND	1110	7
AND	0001	8
EQUIV	1001	9
A	0101	10
B	0011	12
IMPLY	1011	13
OR	0111	14
TRUE	1111	15

Ou seja, ainda faltam: 2, 3, 4, 5 e 11. Bem, se AND e OR e NOT são funcionalmente completos, isso significa que eu consigo expressar esses elementos que faltam como apenas essas operações.

Para 2, 0100, temos a AND NOT b.

3 1100 e 5 1010 são simples negações das entradas. 3 é NOT b e 5, NOT a.

O 4 0010 eu tenho apenas um único bit ligado, e é bastante semelhante ao 2, porém ele ligar com o oposto dos sinais: NOT a AND b.

Finalmente, temos o 11 1101. Aqui, ele só é falso quando o sinal B é verdadeiro e o sinal A é falso. Isso pode ser visto como a negação do 4 0010. Se para 4 tenho NOT a AND b, então para 11 tenho NOT (NOT a AND b).

Pressupostos de circuitos

Aqui estamos lidando com circuitos, que posso pegar um input e dividir ele em vários cantos. Ainda não usei isso no caso das operações faltantes, mas isso é importante porque eu posso e muitas vezes devo repetir um input. Por exemplo, para o XOR, eu preciso criar uma duplicação de sinal:

(a OR b) AND NOT (a AND b)

Eu preciso nesse caso poder usar o sinal A múltiplas vezes, tal qual usar o sinal B também.

Além dessa “puxada de fios”, eu também posso simplesmente ignorar completamente um input. Mas, se não satisfizer ignorar um input e eu precisar usar, existe uma estratégia para isso:

achar uma tautologia com o sinal ignorado
usar um AND com o sinal desejado e a tautologia

E você se pergunta “o que é uma tautologia”? Bem, algo que é simplesmente sempre verdade. E nesse caso a tautologia não é equivalente a um sinal TRUE, a tautologia deriva do input e de portas lógicas. E, sim, essa diferença é importante.

Outra pressuposição importante é que os sinais são discretos e sempre tem o valor de “presente” ou “ausente”. Aqui, um a AND a tem o mesmo valor que um simples a, não há nenhuma espécie de “soma” dos sinais de input.

Derivando os operadores binários usando AND/OR/NOT

Vou continuar usando aqui o sistema de numeração usado em Operações binárias. No caso, por trivialidade eu tenho as operações de valor 14 0111 e 8 0001, já que são literalmente as operações OR e AND e eu tenho acesso a essas operações.

Em cima disso, eu posso obter 1 1000 e 7 1110 negando o resultado dessas operações: NOT (a OR b) vai ser a operação 1 e NOT (a AND b) vai ser a operação 7.

Bem, e se eu quiser eu trivialmente verdadeiro? Diferentemente de uma função zero-ária real, eu preciso derivar do input o valor, pois afinal nos foi dito que AND + OR + NOT é funcionalmente completo. Como fazer isso então?

Bem, tem uma operação que é sempre verdade: OR recebendo um sinal verdadeiro e um sinal falso. Seja com false OR true ou com true OR false, o resultado dessas duas operações é TRUE. Então como consigo fazer essa operação?

Que tal pegar o mesmo sinal, negar ele, e passar tanto ele quanto a sua negação como os inputs de um OR? Exatamente a OR (NOT a). E com isso obtive uma tautologia! Algo que é sempre TRUE!

Se eu quiser usar o sinal de B nesse caso eu posso fazer com ele uma tautologia e aplicar um AND nele. Ou seja, a operação 15 1111, a que retorna sempre TRUE em todas as circuntâncias, pode ser escrita como (a OR (NOT a)) AND (b OR (NOT b)).

Ok, e para o sempre falso? Bem, se eu tenho algo que retorna sempre TRUE, posso só negar isso, algo que é uma contradição. Para o operador 0 0000, posso negar qualquer uma das tautologias ou então simplesmente negar o AND que une as tautologias: NOT ((a OR (NOT a)) AND (b OR (NOT b))).

Para pegar apenas o sinal de A? O operador 10 0101? Posso pegar A com uma tautologia sobre B: a AND (b OR (NOT b))).

Equivalente para o sinal de B, operação 12 0011.

Para NOT a (operador 5 1010) é só negar o resultado do sinal A: NOT (a AND (b OR (NOT b)))). E equivalente para o NOT b (operador 3 1100).

O XOR (como mostrado na seção anterior), que é a operação 6 0110, é (a OR b) AND NOT (a AND b). O EQUIV, operação 9 1001, é a negação disso: NOT ((a OR b) AND NOT (a AND b)).

O IMPLY, operação 13 1011, é NOT (a AND (NOT b)): não pode acontecer de eu ter a premissa mas não ter o consequente.

As operações 2, 4 e 11 já foram mostradas anteriormente em termos dos operadores AND/OR/NOT sobre as entradas, não se faz necessário repetir novamente,

Derivando AND/OR/NOT de NAND

Sabemos que NAND tem completude funcional. Ou seja, eu consigo fazer todas as operações usando apenas o NAND. Então, se eu consigo fazer todas as operações, eu posso fazer também as operações básicas de AND/OR/NOT.

Para fazer o NOT, só lembrar que NAND significa “not and”. E o que acontece se eu aplicar AND para o mesmo sinal? Bem, redundância, retorna ele mesmo, independente de ser TRUE ou FALSE. Ou seja, a AND a é o equivalente a a. E, bem, com um NOT na frente teríamos NOT (a AND a) que é equivalente a NOT a. E, bem, NOT (a AND a) é a definição de NAND aplicado para o mesmo sinal nos dois inputs. Ou seja, já construí o NOT!

E para construit o AND? Eu posso pegar a saída do NAND e aplicar um NOT. Algo como: (a NAND b) NAND (a NAND b). Isso pode ser feito ligando a saída de a NAND b nos dois inputs do NAND seguinte.

Só falta o OR agora. O OR é o operador 14 0111, que é a negação do operador 1 1000. O operador 1 foi descrito acima como NOT (a OR b), mas ele tem uma forma equivalente: (NOT a) AND (NOT b). No caso, me interessa a negação dessa operação: NOT ((NOT a) AND (NOT b)). E, bem, podemos expressar tanto AND como NOT usando apenas NAND, né? Mas, primeiro, NOT (x AND y) é a definição de x NAND y, portanto temos que naturalmente surge um NAND aqui: (NOT a) NAND (NOT b). Finalmente, podemos substituir os NOT x por x NAND x e obter uma forma de OR usando apenas operador NAND: (a NAND a) NAND (b NAND b).

Completude funcional com caranguejos?

Ok, vamos usar caranguejos agora… será que um circuito feito apenas com caranguejos tem completude funcional? As operações disponíveis são:

a OR b
a AND b
(NOT a) AND b
a AND (NOT b)

Infelizmente nenhuma dessas operações disponíveis é capaz de gerar um valor TRUE com base na ausência de caranguejos. Mas… e se eu considerar que além desses 4 operadores eu também possa inserir caranguejos como um input arbitrário? Tipo, se além disso eu tiver um TRUE como operação válida?

Assumindo um input A qualquer na operação (NOT a) AND b, e fixando no input B o valor TRUE, teríamos (NOT a) AND true, que é equivalente a NOT a. E, bem, com isso eu tenho a operação NOT! E eu já tenho garantido as operações AND e OR. AND/OR/NOT é o primeiro exemplo de sistema com completude funcional descrito, portanto as duas portas descritas no artigo junto com a porta que sempre retorna caranguejo é um sistema com completude funcional porque assim consigo simular esses 3 operadores e, portanto, todas as operações booleanas.

Mas… bem, um dos pressupostos é que não há “soma” de valores. E aqui nos caranguejos claramente há a “soma” dos sinais na operação AND: ele vai ter o dobro de caranguejos do que apenas um único sinal de caranguejo. Mas como isso pode interferir? Bem, se eu precisar fazer um a AND (b AND c), por exemplo. b AND c vai ter como output um “sinal” de caranguejo de 2 clusteres, como se tivesse “duas vezes” a força de um sinal de entrada comum. Nessa situação, a colisão do cluster b AND c com o a pode fazer com que o output seja diferente do esperado: memso que tenha sinal em a, em b e em c, é provável que a saída seja FALSE para esse sistema. Nos 3 outputs do segundo tipo de porta que ele apresenta, ele irá sair pelo “output esquerdo”.

Um jeito de lidar com essa questão da “força em excesso” é com alguma espécie de modulador que faz com que o excesso seja descartado. Pode ser até mesmo um caminho estreito com um “abismo” do lado, o que faz com que os caranguejos a mais no cluster caiam e deixe o sinal na força adequada.

E quanto a “divisão” de sinal? Um dos pressupostos dos circuitos era que eu poderia dividir um sinal sem medo de perder valores para poder aproveitar ele em diversos momentos. Mas se eu dividir demais, o sinal fica fraco e ele acaba sendo efetivamente FALSE ao encontrar com outros sinais.

Uma alternativa para isso seria um “amplificador” de sinal: um mecanismo sensível para a presença de caranguejos em um corredor, se detectada a presença de caranguejos, então um caminho com um sinal de caranguejo seria adicionado e “mergeado” com o sinal que vem, como se fosse uma porta OR. Esse acionamento poderia ser um sensor de peso no chão a alguma distância antes do momento do “merge”. A quantidade de caranguejos para o merge pode ter o tamanho ajustado de acordo com a intenção de misturar o sinal antes ou depois de fazer o split do sinal.

Outra coisa para lidar também é o momento de chegada dos sinais, para que não aconteça um “erro” no tiro. Os sinais precisam chegar nas portas lógicas no momento correto. Para isso, eu posso aplicar “atraso” em alguns sinais, mas jamais vou conseguir fazer um sinal ir mais rápido. A ideia aqui é algo semelhante a o que Matt Parker e equipe enfrentaram ao construir um computador de dominós, em alguns momentos ele precisaram deixar um sinal mais lento do que outro para ter a sincronia adequada para a computação em questão. A adição do atraso para se implementar seria simplesmente aumentar o tamanho do percurso que o cluster de caranguejos precisaria percorrer para chegar na porta de operação desejada.

O desafio do atraso também é enfrentado em circuitos eletrônicos tradicionais, mas a implementação do atraso não é sempre “aumentar o tamanho do circuito”, existem portas que causam atraso do sinal mantendo o valor dele.

Computação de bilhar

A computação de bilhar segue princípios bem semelhantes à computação de caranguejos, inclusive muita coisa da computação de caranguejo teve como base a computação de bilhar.

Um dos artigos mais clássicos no assunto é Fredkin & Toffoli 1982 Conservative Logic, e ele considera bolas de bilhar com colisões perfeitamente elásticas entre si e com as paredes. Ele também considera que a superfície na qual a bola desliza (ela não gira!) é ideal e sem atrito.

Diferentemente da computação de caranguejos, as colisões perfeitamente elásticas ajudam para indicar que apenas uma força de sinal irá passar pela porta. Os caranguejos, que são baseados em colisõoes inelásticas (os dois clusters dos sinais se unem), já tem esse desafio a mais.

Para maior aprofundamento de computação de bilhar, outra fonte interessante que achei foi Adamatzky & Durand-Lose 2012 Collision-based Computing.