Monads
Faz algum tempo desde a última vez que escrevo sobre algum padrão de projeto. O último texto que lembro foi o texto sobre CRTP, e nesse tempo meu conhecimento sobre programação aumentou, minhas habilidades comunicativas aumentaram e eu passei a escrever textos melhores. O texto que fiz sobre CRTP, nem acho importante. Entretanto, decidi fazer um texto para explicar monads, pois existe toda essa tradição de que, ao compreender o que é monad, você atinge uma epifania satisfatoriamente envolvente, você sente um desejo incontrolável de tentar compartilhar esse conhecimento com toda a humanidade, e você FALHA, mas, até pior que isso, seu manual é diferente e as pessoas vão perder até mais tempo tentando aprender o que é monad, pois agora há até mais textos confusos que acumulamos.
Eu, é claro, demorei muito tempo para aprender monads, apesar de estar usando monads há bastante tempo. Quando finalmente aprendi o que é monad, percebi o quão simples é esse conceito. Devo essa compreensão ao Douglas Crockford.
Introdução
All told, a monad in X is just a monoid in the category of endofunctors of X, with product × replaced by composition of endofunctors and unit set by the identity endofunctor.
Entendeu? Eu também não, e esse tipo de explicação era uma das razões para eu ter demorado a aprender.
Uma coisa importante para prosseguir com a explicação, é deixar claro os termos utilizados. E o primeiro termo que pretendo deixar claro é o de valor. Em programação funcional pura, não é tão raro assim evitar o uso do termo variável e usar, no lugar, o termo associar (binding em inglês), para indicar que um nome está se referindo a algum valor. Quando você se refere a variável, talvez implicitamente você assuma que você pode mudar o valor dessa variável, mas nem sempre é essa a mensagem que queremos comunicar. Há também o termo objeto, do paradigma de programação orientada a objetos, que podemos usar no lugar do termo variável, mas o termo objeto também carrega outras informações que podem não ser necessárias para a explicação que estamos tentando passar. Por essas razões, eu vou, durante o texto, tentar usar o termo valor, mas se você substituir esse termo por objeto ou variável, ainda é provável que o texto continue fazendo sentido.
Há também o termo função, que em programação pode acabar tendo um significado diferente. Em programação, há o termo subrotina, que não equivale ao termo de função na matemática. Entretanto, algumas linguagens de programação usam o termo função para se referir ao conceito de subrotina, criando uma situação de falso cognato. Para “diminuir” a confusão, passamos a chamar de funções puras, as funções que possuíam o mesmo significado que as funções possuem em matemática. Essa curiosidade não é tão importante para o entendimento de monads, mas é bom que você comece a consumir algumas informações relacionadas para estar estimulado o suficiente quando a explicação de monads aparecer.
Ainda no tópico de funções, temos a diferença de funções membros e funções não-membros. Funções membros são funções que recebem o this/self, que fazem parte de alguma classe e não são métodos estáticos, funções que chamamos de métodos na programação orientada a objetos. Funções não-membros são funções livres, que não fazem parte de nenhuma classe. Quando eu me referir a uma função que recebe a e b como argumentos, as duas situações exemplificadas no seguinte código são interpretações válidas:
| class X {}; | |
| void foo(X a, int b); | |
| class Y | |
| { | |
| public: | |
| void foo(int b); | |
| }; | |
| int main() | |
| { | |
| int b; | |
| // Interpretação #1 | |
| { | |
| X a; | |
| foo(a, b); | |
| } | |
| // Interpretação #2 | |
| { | |
| Y a; | |
| a.foo(b); | |
| } | |
| } |
Nos dois casos, temos uma função foo que recebe a e b como argumentos. Há até esforços para tornar a sintaxe de chamada de funções em C++ mais uniforme. A linguagem Rust está ligeiramente à frente nessa corrida, enquanto outras linguagens já chegaram lá.
Você pode enxergar monad como um padrão de projeto, e, dentro desse padrão de projeto, há o “objeto” que de fato representa o monad. Assim como ocorre no padrão Singleton, onde o mesmo termo, Singleton, se refere (1) ao padrão de projetos e a (1) um objeto que respeita algumas características. Estou citando o padrão Singleton, porque esse é, pela minha experiência, o padrão mais famoso e mais fácil de entender. A parte importante para manter em mente é que monad é um valor, mas, em alguns momentos, pode ser que eu me refira a monad como um padrão de projeto.
Valores embrulhados
Em alguns cantos na terra da programação, podemos encontrar valores que são embrulhados. Por exemplo, temos a classe Integer, na linguagem Java, que embrulha um valor primitivo int. Temos também, em C++, a classe auto_ptr<T>, que embrulha um valor do tipo T. Instâncias dessas classes não são monads.
Valores embrulhados por outro valor são isolados, tornando-se acessíveis somente a partir de uma interface. Eles não podem ser acessados diretamente, pois estão embrulhados em outro valor, seja lá qual for o propósito. No caso da classe Integer, você precisa usar a função intValue para acessar o valor embrulhado. No caso da classe auto_ptr<T>, você precisa usar a função que sobrecarrega o operador de desreferenciamento da classe.
Monads também embrulham valores. Monads são valores que embrulham outros valores e apresentam três propriedades. Entretanto, eu só vou informá-las ao final do texto.
Função unit e função bind
Unit é uma função que recebe como argumento o valor a ser embrulhado e retorna o monad. É também conhecido como construtor em outros locais. Seria o “construtor” do monad.
| function unit(val) { | |
| return { /* ... */ val /* ... */}; | |
| } |
Bind é uma função que recebe dois argumentos, um monad e uma função que tenha a “mesma assinatura” de unit, e retorna um novo monad. Usei a expressão “mesma assinatura” entre aspas, pois, na verdade, a situação não precisa ser tão estrita assim. O tipo de retorno pode ser um monad diferente, mas o argumento de entrada precisa ser do mesmo tipo ou compatível.
| // LEMBRETE: monad é um padrão, e sua implementação não precisa ser exatamente assim: | |
| function bind(monad, f) { | |
| return f(monad.value); | |
| } | |
| // bind também podia ser uma função-membro, possibilitando algo do tipo: | |
| monad.bind(f_1).bind(f_2).bind(f_3); |
Em um monad, deve existir uma forma de acessar o valor embrulhado através da função bind, mesmo que essa não seja a única forma de acessar o valor, e mesmo que a função receba outro nome que não seja bind. Daí que encontramos algumas discussões usando termos como “monadic operations“.
A ideia por trás dessa estrutura é a componibilidade. Talvez não seja tão incrível para eu ou você, pois estamos acostumados a ter outras ferramentas disponíveis, mas parece ser um conceito incrível para os programadores da comunidade de programação funcional pura.
Em Haskell, monads costumam ser usados para isolar comportamentos que não são livres de efeitos colaterais, como I/O. Rust, uma linguagem que possui “;”, não precisa de monads, mas o núcleo de seu sistema da tratamentos de erros é feito em cima das ideias de monads.
Alguns monads
Maybe
Maybe é um monad, em alguns locais recebendo o nome de Option ou optional, e às vezes nem sequer obedecendo as propriedades de um monad. O propósito de Maybe é simples: possivelmente armazenar um valor. Você pode encarar esse monad como uma abstração que lhe permite expressar a semântica de valores opcionais, que em C são representados através de ponteiros que possivelmente possuem o valor NULL, ou em Java, onde qualquer objeto pode ser null.
O legal desse monad é que você ganha segurança, pois verificar pela existência do valor para então acessá-lo não acontece. É mais seguro, porque, no modelo antigo, era possível você tentar acessar o valor esquecendo de verificar antes se ele existia, esquecer do if. Com o padrão de monad/Maybe, você só usa a função bind que já recebe o valor “extraído” e ela só é chamada se o valor for diferente de None.
| int non_maybe_version(int *v) | |
| { | |
| if (v) | |
| return *v; | |
| return 0; | |
| } | |
| int maybe_version(Maybe<int> v) | |
| { | |
| int ret = 0; | |
| v.bind([&ret](int v) { | |
| ret = v; | |
| }); | |
| return ret; | |
| } |
A verdade é que esse monad fica bem mais legal se houver suporte a nível de linguagem para exhaustive pattern matching, como ocorre em Rust. Em Rust, a abstração que equivale a esse monad é a abstração Option.
Na verdade, o exemplo de código anterior usa um bind “não-conformante”, pois a função/closure passada como argumento não retorna outro monad, mas escrevi mesmo assim para ser breve. Pattern matching costuma ser mais interessante para acessar o valor e você abstrai outros comportamentos que são mais interessantes para serem encapsulados como “operações monádicas” (a documentação da abstração Option em Rust é um ótimo exemplo).
Result
Se Maybe é a abstração para valor-ou-nada, Result é a abstração para valor-ou-erro. Suponha uma função que converta uma string para um inteiro de 32 bits. Erros podem acontecer e pode ser que você queira usar o Maybe<int> como retorno da função, mas talvez seja interessante diferenciar o porquê da função ter falhado, se foi devido a uma string inválida ou overflow, por exemplo.
Result como monad é bem interessante, porque lhe permite encadear uma cadeia de ações e, caso alguma delas retorne erro, a cadeia para, e o erro é armazenado, sem que você precise explicitamente verificar por sua existência. Na linguagem Rust, até existe uma macro, try!, que torna o código até mais legível a agradável.
É interessante ter operações monádicas em Result que só atuam em um dos valores (o esperado ou o valor de erro), então você teria Result<T, E>::map e Result<T, E>::map_err.
Future
Futures e promises se referem a um padrão na computação para abordar o problema de concorrência e dependência de dados. Nesse padrão, o future é um valor que embrulha o resultado, que é computado assincronamente. Alguma função como get pode ser usada para obter o resultado e, caso não esteja pronto, a thread atual é bloqueada até que ele esteja disponível.
A adição de operações monádicas permite definir uma API que anexe continuações que seriam executadas quando o resultado estiver pronto, livrando-lhe do problema de bloquear a thread atual (que essencialmente mata o paralelismo). C++ é uma linguagem que atualmente possui abstrações de futures e promises, mas não possui as operações monádicas que tornariam essa abstração muito mais agradável de ser utilizada, como é explicado em um bom texto do Bartosz Milewski.
Programadores de NodeJS querem usar futures para se livrar de códigos profundamente aninhados (também conhecido como nesting hell). Futures são monads que podem livrar o programador da verificação explícita de erros para cada operação. Se bind for uma função-membro, o aninhamento infernal é, de fato, eliminado. O benefício é um ganho na legibilidade que pode ter grandes consequências como produtividade aumentada e diminuição de erros.
As três propriedades de um monad
| unit(value).bind(f) === f(value); | |
| monad.bind(unit) === monad; | |
| (monad.bind(f).bind(g) | |
| === monad.bind(function(value) { return f(value).bind(g); })) |
A terceira propriedade existe para garantir ordem. E isso é importante para composibilidade.
Conclusão
Utilidade. A utilidade de você entender monads é que agora, quando os programadores de Haskell invadirem sua comunidade de programação, você vai entender o que eles querem dizer por monad. A utilidade se resume a comunicação, mas eu não recomendo que você use o termo monad para documentar abstrações que você crie que modelem o conceito de monad, pois é inútil. Dizer que uma abstração modela o conceito de monad não vai me fazer querer usar tal abstração. Demonstrar a utilidade da abstração vai me fazer querer usá-la e omitir o termo monad não vai tornar a demonstração mais longa ou menos clara. Só use o termo monad para questão de comunicação, quando você estiver tentando se comunicar com programadores de Haskell.
Vinipsmaker labs 
Comentários