DEV Community: Lucas Perez

Não use uma variável chamada path dentro de funções quando estiver usando o zsh

Lucas Perez — Wed, 20 Mar 2024 21:56:23 +0000

🏴󠁧󠁢󠁥󠁮󠁧󠁿 English version here.

Antigamente eu criava aliases para coisas comuns, como uma sequência de comandos ou comandos com flags e opções específicas. Porém, quando ficava muito complicado, eu criava um shell script para lidar com coisas mais complexas. Aí então eu criava aliases que simplesmente chamavam esses scripts. Eu preferia isso do que por o script no meu path porque daí meus scripts podiam ter nomes descritivos e eu não teria que ficar lidando com alterar a variável PATH

Mas daí em algum momento eu percebi que eu podia simplesmente criar funções nos arquivos de configuração do meu shell (como por exemplo o .bashrc, o .zshrc etc) e daí eu teria essas funções disponíveis para mim. Além disso, usando a estratégia script+alias, quando eu executava which <comando>, eu não teria uma saída tão útil assim, pois aparecia para mim algo como comando=/caminho/para/o/script. Mas quando eu defino funções, executar which <função> me mostra a implementação dela.

Eu acho que o comportamento de which não é o mesmo em todas as distros, mas no Fedora ele faz isso.

É claro que se a implementação de tal função for muito grande, talvez mostrá-la não seja tão útil assim, mas enfim.

Você pode basicamente copiar e colar seus shell scripts em definições de funções, só tem que lembrar que muito provavelmente você vai querer trocar exit por return.

Ou será que não?

Hoje eu queria criar uma função que chamaria um curl pra pegar um token de autorização, e depois usaria esse token em outro curl para uma rota fornecida como argumento. Isso para que eu não tenha que sair copiando e colando tokens o dia todo e ficar passando um --header pro curl toda hora só pra trabalhar na minha API.

Então eu fiz algo mais ou menos assim:

curl-da-minha-api() {
  token=`curl ... | jq -r '.token'`
  path="$1"
  shift
  curl \
    --header "Authorization: Bearer $token" \
    --url "http://localhost:3000/$path" \
    "$@"
}

O que eu queria era passar o caminho como primeiro argumento pra função e colocar depois de http://localhost:3000 (para que eu não tenha que escrever isso toda hora. Somos preguiçosos, certo?). Eu também queria poder passar mais opções para o segundo curl que é feito. Então eu pego o primeiro argumento com $1, faço um shift pra removê-lo da lista de argumentos, e simplesmente passo o resto pro segundo curl.

Então eu posso fazer coisas assim:

# Faz um GET para http://localhost:3000/posts
curl-da-minha-api /posts

Mas também posso fazer coisas assim:

# Faz um POST para http://localhost:3000/posts com aquele corpo
curl-da-minha-api /posts -X POST -d '{"title": "Post Legal"}'

Isso deixa minha função flexível, eu apenas tenho que saber que exatamente o PRIMEIRO argumento é o path. Eu poderia iterar sobre os argumentos, usar getopts ou algo assim, mas eu apenas queria fazer algo rápido e que funcionasse.

Porém!!

Quando eu fui executar essa função, eu tive um erro esquisito:

$ curl-da-minha-api /posts
curl: Command not found

Eu pensei, o quê? Como assim? Eu tenho curl instalado. Vamos editar o arquivo onde eu defini a função:

vim ~/.zshrc
vim: Command not found

Praticamente todo comando que eu tentei a partir daqui dava o mesmo erro, inclusive ls, cd etc.

O que está acontecendo? Por que minha função não só não funcionou, como também aparentemente estragou minha sessão no terminal?

A mensagem de erro não é muito claro. Eu pensei, vou por essa função num shell script e executá-lo com a opção -x pra conseguir debugar melhor. Mas quando eu fiz isso, a função simplesmente funcionou! Sem problemas com nada!

Depois de quebrar minha cabeça, eu tive uma ideia. Talvez a linha path=... fosse um problema. Eu renomeei a variável simplesmente para p e agora a função funcionava perfeitamente.

E ainda mais esquisito, eu tentei executar a mesma função usando nosso bom e velho amigo bash, e eu sabe o quê? Não teve nenhum problema usando a variável chamada path. Então parece que tem alguma magia misteriosa acontecendo com o zsh.

E por falar nisso, eu alterei minha função para usar local p=... quando definia a variável. Usando o local impedia a função de estragar tudo quando eu usava o nome path, assim: local path=.... Porém, a função continuava não funcionava. Interessante. E daí eu pensei, será que o zsh pode usar tanto path como PATH?

Bom, parece que sim! No zsh, se você fizer echo $path, você vai receber a mesma coisa que se fizer echo $PATH! Então aí está, como eu estava criando uma variável chamada path, ela estava sobreescrevendo a minha variável de ambiente PATH! Por isso que usar local salvou meu terminal, porque quando não usava, esse valor sobreescrito afetava tudo mesmo após a função ter terminado.

No bash, executar echo $path simplesmente não retorna nada. Eu também tentei no zsh fazer echo $home, mas isso não mostra nada também. Então estranhamente, o zsh não faz diferença entre maiúsculas e minúsculas somente para a variável do path. Mas em todas as outras variáveis que tentei, maiúsculas e minúsculas importavam, seja x, minhavariável ou shell.

Além disso, todos os meus scripts eu faço usando o shebang /sh, por isso eu não tive problemas quando copiei e colei minha função em um script. Seja lá o que estiver em /sh no meu computador, ele faz diferença entre path e PATH.

E enquanto eu escrevia isso, eu decidi googlear um pouco (mas não enquanto tentava resolver esse problema, porque a gente é preguiçoso apenas para escrever localhost, e não para depurar programas, certo?). Aparentemente, esse comportamento de usar path e PATH também está presente no csh e no tcsh. Além disso, eu ACHO que o zsh foi baseado/inspirado no tcsh e no ksh (eu acho, não me cobrem depois), então talvez venha daí essa coisa.

E também para deixar claro, não é que o zsh não diferencia maiúsuclas e minúsculas para o path. O que acontece é que ele entende ambos path e PATH, porque coisas como PaTh e PAth não funcionam). Percebi isso posteriormente com mais testes.

Pra ser sincero, eu acho isso meio esquisito e fere um pouco o "princípio da surpresa mínima" (tem esse nome em português? Estou falando disso). Mas acho que hoje aprendi
algo novo.

Aprendi que o zsh não diferencia path e PATH.
Além disso, usem local em suas funções!

TIL: Don't set a variable named path inside functions when using zsh

Lucas Perez — Wed, 20 Mar 2024 21:22:05 +0000

🇧🇷🇵🇹 Versão em português aqui.

In the past, I used to use aliases for common things, sometimes a sequence of commands or commands with specific flags and options. But when it got too complicated, I used to create shell scripts to handle more complex logic. Then I would create aliases that just call these shell scripts. I prefered this over putting the scripts in my path because then I could name then with more descriptive names and I wouldn't have to deal with the PATH variable.

But at some point I realized that I can just create functions and put then in my shell config file (like .bashrc, .zshrc etc) and then I would have these functions available to me. Also, using the script+alias aproach, running which <command> wouldn't be all that useful, it would just show me something like command=/path/to/script. But when I define functions, running which <function> shows me the implementation of it.

I think the behaviour of which is not the same on every distro, but on Fedora it does that.

Of course that if the implementation is several lines long, it might not be helpful anyways, but anyways.

You can pretty much copy paste your shell scripts into functions definitions, just have in mind that instead of using exit, you should use return.

Or can you?

Today I wanted to create a function that would call curl to get an authorization token, and then use this token to make another curl to a supplied route, so I wouldn't have to copy paste around a token the whole day and deal with yet another --header flag in curl just to develop my API.

So I did something like this:

my-api-curl() {
  token=`curl ... | jq -r '.token'`
  path="$1"
  shift
  curl \
    --header "Authorization: Bearer $token" \
    --url "http://localhost:3000/$path" \
    "$@"
}

What I wanted was to supply the path as the first argument to the function and append it to localhost:3000 (so I don't have to type so much all the time. We're lazy, right?). And then I would like to pass curl flags to my function so it would repass it to curl internaly. So I grab the first argument with $1, I do a shift to remove it from the arg list, and pass the rest as is to curl.

So I can do things like this:

# Do a GET to http://localhost:3000/posts
my-api-curl /posts

But I can also do things like this:

# Do a POST to http://localhost:3000/posts with that body
my-api-curl /posts -X POST -d '{"title": "Nice Post"}'

This makes my function flexible, I just have to know that the FIRST argument is the url. I could iterate over the arguments, use getopts or something, but I was doing something dirt and quick.

So when I was going to run this function, I got a weird error:

$ my-api-curl /posts
curl: Command not found

I thought, what? I do have curl. Lets edit the file where I define it:

vim ~/.zshrc
vim: Command not found

Pretty much every command I tried from here on would say Command not found, I could not use ls, cd etc.

What is going on? Why didn't my function work, and why did it bork my terminal session?

The error message is not very clear. I wanted to run it as a script with the -x flag for debugging purposes, but when I copy pasted it into a file and ran it with sh, it just worked! No problems with it!

After some scratching my head, I had a hunch that the line path=... was troublesome. I renamed the variable to simply p and now the function works.

And even weirder, I tried the same using our trusty old friend bash, and I had no problem with using a variable named path. So I guess there is some weird zsh magic going on there.

And by the way, I updated my function to use local p=... when defining the variable. When doing so, it does not bork my terminal session if I use local path=..., but the function itself does not work. Interesting. And then I thought, maybe zsh can use both path and PATH?

Well, it is true! In zsh, if you echo $path, you'll get the same thing as echo $PATH! So there you go, since I was using a variable named path, it was overriding my PATH env var! That's why using local saved my terminal, because when not using it, this overwritten value would affect everything, not just the function.

In bash, echo $path just outputs nothing. I also tried in zsh to echo $home, but this outputs nothing as well. So weirdly, zsh is case insensitive only for the path variable. It is not case insensitive for any other variable I tried, be it x, myvariable or shell.

All my scripts shebangs are /sh though, so that's why I didn't have a problem when I copy pasted my function to a script, it worked well, because whatever /sh is in my computer, it is not case insensitive for my PATH variable.

And while writing this, I decided to try some googling (I didn't while I was solving the problem, because I like figuring things on my own. We're just lazy to type, not to debug, right?), it looks like this is also the behaviour of csh and tcsh. Also, zsh is kind of based on tcsh and ksh I think (don't quote me on that), so maybe that's where it comes from.

Also, zsh is not actually case insensitive, since pAth, PAtH etc does not work. It simply understands both path and PATH. I learned that with further experiments.

To be honest, I thing this is weird and kind of hurts the principle of least surprises, but I guess today I learned.

TIL zsh is somewhat case insensitive for the PATH.
Also, use local in your functions!

Histórico do Bash dentro de Contêineres Docker

Lucas Perez — Wed, 25 May 2022 13:10:13 +0000

🏴󠁧󠁢󠁥󠁮󠁧󠁿 English version of this text here!

Não sei vocês, mas eu adoro ter um ambiente de desenvolvimento dockerizado. Não ter que me preocupar com versionamento e dependências quando for pulando de projeto em projeto é muito bom.

Mas algo que eu não gosto tanto assim é quando eu saio do contêiner e mais tarde volto nele e descubro que perdi o histórico de todos os comandos anteriores, então não posso buscar mais nada nem com ctrl+R nem com seta pra cima/ctrl+P. Imagens de dor e sofrimento!

Decidi então tentar manter esse histórico, e para fazer isso, primeiro eu pensei, como que o bash faz pra saber os comandos anteriores?

No fim parece que há uma variável de ambiente chamada HISTFILE que contém o caminho para um arquivo de texto com o histórico de comandos do bash. Aparentemente, por padrão ela é configurada para $HOME/.bash_history.

OBS: Se o teu contêiner rodar outro shell diferente do bash, teríamos que descobrir onde que esse outro shell guarda o seu histórico.

Então uma solução que encontrei foi de mudar essa variável de ambiente pra algum outro lugar, algum lugar dentro do diretório do projeto que estou trabalhando pra evitar perdê-lo depois de parar o contêiner.

Vamos supor que a imagem do docker cria um diretório /app com todo o conteúdo do projeto dentro, eu poderia definir HISTFILE como sendo /app/.bash_history, e daí se mapearmos tudo com um volume, vamos ter um histórico persistente entre sessões do docker. O nome do arquivo em si nem precisa ser .bash_history, poderia ser algo como /app/.docker_bash_history, por exemplo.

Pra começar um contêiner com uma variável específica, podemos passar a opção -e:

docker exec -it -e HISTFILE=/app/.bash_history -v <volume> <...outras coisas...>

Se estivermos usando o Docker Compose, podemos ou passar um "env file" (um arquivo com variáveis de ambiente) ou as variáveis diretamente no docker-compose.yml (ou qualquer outro arquivo de configuração que estejas usando):

# arquivo de configuração de exemplo

services:
  app:
    build: .
    volumes:
      - .:/app # mapeando este volume para persistir as modificações no nosso novo arquivo de histórico
    command: echo Oi!
    env_file: # podemos definir as variáveis dentro deste arquivo .env
      - .env
    environment: # ou então podemos passá-las diretamente aqui
      HISTFILE: /app/.bash_history

Um problema surge com essa solução, entretanto. Agora eu tenho um arquivo novo na raiz do meu projeto, um arquivo que o git vai ver, a menos que eu o coloque no nosso .gitignore, coisa que eu realmente acho que devíamos. Eu não quero commitar meu histórico e nem quero puxar o histórico de outras pessoas, até porque isso acabaria com o propósito de ter um arquivo de histórico. Além disso, acabei de criar um novo arquivo na raiz, que pode ficar poluindo o diretório base do projeto. Talvez aches um outro lugar melhor para esses arquivos.

E isso é praticamente tudo! Eu não sei o quão ruim ou boa é essa ideia, mas estou gostando até aqui. Eu criei um diretorio novo na raiz do projeto, dotfiles/, que tem também outros arquivos parecidos, como .irb_history e .irbrc em um projeto ruby. Pra conseguir ter isso tudo funcionando, eu tive que adicionar as seguintes linhas ao arquivo dotfiles/.irbrc:

require 'irb/ext/save-history'
IRB.conf[:SAVE_HISTORY] = 10_000
IRB.conf[:HISTORY_FILE] = ENV['IRB_HISTFILE']

E agora definir não somente a variável HISTFILE como também
as variáveis IRBRC e IRB_HISTFILE, assim:

HISTFILE=/app/dotfiles/.bash_history
IRBRC=/app/dotfiles/.irbrc
IRB_HISTFILE=/app/dotfiles/.irb_history

Uma nota importante sobre o IRB, se você deixar o arquivo .irbrc na raiz, toda vez que você abrir o IRB, ele vai usar o .irbrc do projeto, visto que ele é encontrado primeiro. Isso pode não ser desejado, talvez você queira usar o seu próprio IRB normal. Nesse caso, colocar o arquivo .irbrc dentro de outro diretório, como dotfiles/, passa a ser essencial.

Obrigado por lerem! (:

Bash history inside Docker Containers

Lucas Perez — Wed, 25 May 2022 13:09:55 +0000

🇵🇹 Versão em português deste texto aqui! 🇧🇷

I don't know about other people, but I love having a docker development environment. Being able to just run a docker container with all the dependencies taken care of for all projects, handling versions and etc is just too good.

But what I don't love is when I exit the container and later start it again to realize I have lost all the previous commands, so I can neither crtl+R nor up/ctrl+P to find them. Sad times!

So I decided to try to keep this history, and in order to figure out how to do that, I first thought, how does bash itself knows the previous commands?

It turns out there is an env var named HISTFILE, which will contain a path to a text file with the bash history. Apparently, by default it is set to $HOME/.bash_history.

OBS: If your container does not run bash, but rather some other shell, we would have to find out where this other shell puts its history file.

So a workaround I have found is to change this env var to somewhere else, somewhere inside the project's dir that I'm working on to avoid losing it after stopping the container.

Lets say that the docker image builds a /app folder with all the contents of the directory of the project I'm working on inside it, I could set HISTFILE to /app/.bash_history, and if we map with a volume with the project's dir contents, I would have a persistent history of commands between docker sessions. The file name itself doesn't even have to be .bash_history, it could be something like /app/.docker_bash_history, for example.

To start a container with a specific variable, we can use the -e option:

docker exec -it -e HISTFILE=/app/.bash_history -v <volume> <...other stuff...>

If we are using Docker Compose, we could either pass an env file or the direct variables to it in the docker-compose.yml (or other config file you may be using):

# example config file

services:
  app:
    build: .
    volumes:
      - .:/app # mapping this volume to persist modifications to our new history file
    command: echo Hi!
    env_file: # we can define the variables inside the .env file
      - .env
    environment: # or we can pass them directly here
      HISTFILE: /app/.bash_history

A problem with this approach arises, though. I now have a new file in my project's root, a file that git will see, unless we put it in our .gitignore, and I really think we should. I don't want to commit my history nor do I want to pull other people's history, because this would defeat the purpose of having a history file. Other than that, I just created a new file in the root, which could cause some noise and litter the root folder. Maybe you can find a better place other than the app's highest level folder.

And that's pretty much it. I don't know how bad or good of an idea this is, but I'm enjoying it so far. I created a dotfiles/ folder inside the root that also has other dot files, like .irb_history and .irbrc in a ruby project. In order to get it working, I had to put this in dotfiles/.irbrc:

require 'irb/ext/save-history'
IRB.conf[:SAVE_HISTORY] = 10_000
IRB.conf[:HISTORY_FILE] = ENV['IRB_HISTFILE']

And then define not only HISTFILE, but also IRBRC and IRB_HISTFILE environment variables, like this:

HISTFILE=/app/dotfiles/.bash_history
IRBRC=/app/dotfiles/.irbrc
IRB_HISTFILE=/app/dotfiles/.irb_history

An important note on IRB, if you leave the .irbrc file in the root folder, everytime you fire up IRB, it is going to use the project's .irbrc, since it is the first found config file for IRB. This could be undesirable, though. In this case, putting the .irbrc inside another directory, like dotfiles/, becomes essential.

Thanks for reading! (:

Funções recursivas e anônimas em Elixir

Lucas Perez — Thu, 24 Feb 2022 17:53:59 +0000

🏴󠁧󠁢󠁥󠁮󠁧󠁿 English version of this text here!

Um tempo atrás, eu tentei criar uma função recursiva e anônima em Elixir porque eu estava dentro do iex e estava com preguiça de criar um módulo dentro do repl. Minha primeira tentativa foi algo assim:

# Fatorial ingênuo, anônimo e recursivo
fact = fn
  0 -> 1
  n -> n * fact.(n-1)
end

OBS: Sim, é possível definir múltiplas cláusulas para funções anônimas!

É claro que isso não funcionou, porque fact/1 ainda não está definida no momento em que é chamada dentro do corpo da função.

Eu realmente não lembro por que eu precisava de uma função anônima e recursiva, mas no começo dessa semana eu percebi o que que eu tinha que fazer para que funcionasse. Tudo o que temos que fazer é assegurar-nos que a função existe no momento em que é chamada, certo?

E se a função anônima recebesse, então, outra função como argumento, e essa função recebida fosse a que faz a chamada recursiva?

Agora o Elixir não poderia reclamar da função não estar definida, porque ela foi fornecida via um argumento, que poderia ser qualquer coisa:

fact = fn
  0, _ -> 1
  n, recur -> n * recur.(n-1)
end

Bom, mas o que é essa função recur?

Ela poderia muito bem ser a própria fact! Somente temos que passá-la quanto a estivermos chamando:

fact = fn
  0, _ -> 1
  n, recur -> n * recur.(n-1)
end

# Passe fact para si mesma, para que ela seja "recur" dentro do corpo da função
fact.(4, fact)

É claro que isso vai lançar uma exceção, pois agora fact tem uma aridade de 2, e recur está sendo chamada com apenas um argumento. Lembre-se que recur é de "facto" fact! Sim, tentei fazer um trocadilho.

Para resolver isso, tudo que temos que fazer é chamar recur passando recur para si mesmo, assim:

fact = fn
  0, _ -> 1
  n, recur -> n * recur.(n-1, recur)
end

fact.(4, fact)

#=> 24

Também funciona com recursão de cauda, é claro. Tudo que teríamos que fazer é gerenciar os parâmetros e retornos corretamente.

Legal, posso usar isso num Enum.map ou alguma outra função de ordem superior?

Bom, somente se tomarmos cuidado.

Se escrevermos isso:

fact = fn
  0, _ -> 1
  n, recur -> n * recur.(n-1, recur)
end

Enum.map([1,2,3,4], fact)

Então Enum.map/2 tentará invocar fact com um argumento apenas, lançando uma exceção.

Uma maneira de resolver isso seria encapsulando-a dentro de uma outra função:

fact = fn
  0, _ -> 1
  n, recur -> n * recur.(n-1, recur)
end

Enum.map([1,2,3,4], &(fact.(&1, fact)))

#=> [1, 2, 6, 24]

Outra maneira seria definir fact com uma interface mais legal.

A função fact poderia simplesmente receber um argumento e daí definir a função anônima e recursiva dentro de si mesma, e daí chamar a função anônima recém definida passando a mesma como argumento.

Seria algo assim:

fact = fn n ->
  do_fact = fn
    0, _ -> 1
    n, recur -> n * recur.(n-1, recur)
  end

  do_fact.(n, do_fact)
end

Enum.map([1,2,3,4], fact)

#=> [1, 2, 6, 24]

Agora nós temos uma função recursiva e anônima que funciona como o esperado. Se eu quiser saber o fatorial de um número, apenas tenho que passar o número para a função, que é exatamente o que Enum.map tentará fazer.

Até definir na mesma linha essa função anônima funcionará:

Enum.map([1,2,3,4], fn n ->
  do_fact = fn
    0, _ -> 1
    n, recur -> n * recur.(n-1, recur)
  end

  do_fact.(n, do_fact)
end)

#=> [1, 2, 6, 24]

E recursiva de cauda:

Enum.map([1,2,3,4], fn n ->
  do_fact = fn
    0, acc, _ -> acc
    n, acc, recur -> recur.(n-1, n*acc, recur)
  end

  # Lembre-se de definir corretamente o valor inicial do acumulador. Aqui ele é 1
  do_fact.(n, 1, do_fact)
end)

#=> [1, 2, 6, 24]

Ter uma interface mais legal não é bom somente para usá-la como argumentos de uma função de order superior, também é mais legal para nós invocarmos essa função, é claro:

fact = fn n ->
  do_fact = fn
    0, acc, _ -> 1
    n, acc, recur -> recur.(n-1, n*acc, recur)
  end

  do_fact.(n, 1, do_fact)
end

# Não há necessidade de passar nem o acumulador nem a própria função
fact.(4)
#=> 24

Agora se eu quiser saber o fatorial de 4, tenho que apenas chamar a função fact/1 com 4 como argumento, sem ter essas coisas estranhas de passar a própria função por aí manualmente na chamada.

Legal, mas isso é útil?

Para ser sincero, eu não sei.

Para começo de conversa, não é ilegal definir um módulo dentro do repl, então o cenário de "Estou com preguiça dentro do iex" não é tão importante assim. Quero dizer, eu tive que escrever tanta coisa a mais só para criar essa função recursiva e anônima que talvez simplesmente escrever defmodule M do ... end seja mais fácil e mais rápido.

Outra situação em que poderíamos usar isso seria em arquivos elixir normais onde temos algums Enums ou outras funções de ordem superior trabalhando, mas daí a gente provavelmente já vai estar dentro de um módulo, onde poderíamos definir uma função privada "com nome" (não anônima) para fazer esse trabalho e já dando um nome significativo a ela, aproveitando que vamos estar ali. Isso vai culminar num código melhor e mais legível do que a "solução" com as funções recursivas e anônimas malucas.

Mas ei, mesmo que isso não seja assim tão útil, pelo menos é sempre legal pensar sobre funções e recursão, certo?

E também foi bem divertido escrever esse post! 😁

É isso por hoje. Obrigado por ler e tenha um bom dia! (:

Recursive anonymous functions in Elixir

Lucas Perez — Thu, 24 Feb 2022 17:25:13 +0000

🇵🇹 Versão em português desse texto aqui! 🇧🇷

Some time ago I tried to create a recursive anonymous function in Elixir because I was inside iex and was feeling lazy about creating a module inside the repl. My first attempt was something like this:

# Anonymous recursive naive factorial
fact = fn
  0 -> 1
  n -> n * fact.(n-1)
end

Side note: Yes, you can define multiple clauses for anonymous functions!

This, of course, does not work, because fact/1 is not yet defined when it is called inside the function body.

I really do not remember why I needed a recursive anonymous function, but early this week I realized what I had to do in order to make it work. All we have to do is make sure the recursive function exists at the moment it is called, right?

So what if the anonymous function receives another function as an argument, and this received function is what is going to make the recursive call?

Now Elixir could not complain about the function not being defined, because I was supplied as an argument, which could be anything:

fact = fn
  0, _ -> 1
  n, recur -> n * recur.(n-1)
end

Well, but what is this recur function?

It could very well be fact itself! We just have to pass it when calling:

fact = fn
  0, _ -> 1
  n, recur -> n * recur.(n-1)
end

# Pass fact to itself, so it will be "recur" inside the function body
fact.(4, fact)

Of course this will raise an exception, because now fact has an arity of 2, and recur is being called with only one argument. Remember that recur is in fact fact! No pun intended.

To solve this, all we have to do is to call recur passing recur to itself, like this:

fact = fn
  0, _ -> 1
  n, recur -> n * recur.(n-1, recur)
end

fact.(4, fact)

#=> 24

It works with tail recursion as well, of course. All you have to do is manage the parameters and returns correctly.

Nice, can I use it in an Enum.map or any other higher order function?

Well, only if we are careful.

If we write this:

fact = fn
  0, _ -> 1
  n, recur -> n * recur.(n-1, recur)
end

Enum.map([1,2,3,4], fact)

Then Enum.map/2 will try to invoke fact with one argument only, raising an exception.

One way to solve this would be to wrap it into another function:

fact = fn
  0, _ -> 1
  n, recur -> n * recur.(n-1, recur)
end

Enum.map([1,2,3,4], &(fact.(&1, fact)))

#=> [1, 2, 6, 24]

Another way would be to define fact with a nicer interface.

The fact function could just receive an argument and then define the recursive anonymous function inside itself, and then call the just defined anonymous function passing it as the argument.

Something like this:

fact = fn n ->
  do_fact = fn
    0, _ -> 1
    n, recur -> n * recur.(n-1, recur)
  end

  do_fact.(n, do_fact)
end

Enum.map([1,2,3,4], fact)

#=> [1, 2, 6, 24]

Now we have a recursive anonymous function that works as expected. If I want to know the factorial of a number, I just have to pass the number to it, which is what Enum.map will try to do.

Even inline definition of this anonymous function will work:

Enum.map([1,2,3,4], fn n ->
  do_fact = fn
    0, _ -> 1
    n, recur -> n * recur.(n-1, recur)
  end

  do_fact.(n, do_fact)
end)

#=> [1, 2, 6, 24]

And tail recursive:

Enum.map([1,2,3,4], fn n ->
  do_fact = fn
    0, acc, _ -> acc
    n, acc, recur -> recur.(n-1, n*acc, recur)
  end

  # Remember to correctly set the accumulator's initial value. Here it is 1
  do_fact.(n, 1, do_fact)
end)

#=> [1, 2, 6, 24]

Having a nicer interface is not only good to use it as arguments of higher order functions, it is also nicer for us to invoke it normally, of course:

fact = fn n ->
  do_fact = fn
    0, acc, _ -> 1
    n, acc, recur -> recur.(n-1, n*acc, recur)
  end

  do_fact.(n, 1, do_fact)
end

# No need to pass the accumulator nor the function itself
fact.(4)
#=> 24

Now if I want to know the factorial of 4, I just have to call the function fact/1 with 4 as an argument, no weird passing itself around manually on function calls.

Nice, but is this useful?

To be sincere, I do not know.

For starters, it is not ilegal to define a module inside the repl, so the "I'm lazy in iex" scenario is not all that meaningful. I mean, I had to write so much extra content just to create this anonymous recursive function that simply writing defmodule M do ... end might be easier and faster.

Another situation where we could use this would be in normal elixir files where we have some Enum functions or other higher order functions work, but then we would probably already be inside a module, where we could define a named private function to do this work and give it a meaningful name while we're at this, culminating in a better, more readable code than the "solution" with the crazy recursive anonymous functions.

But hey, even if it is not all that useful, at least it is always nice to think about functions and recursion, right?

And it was also very fun to write this post! 😁

That's it for today. Thanks for reading, and have a nice day! (:

Como mostrar apenas os commits da branch atual

Lucas Perez — Mon, 04 Oct 2021 18:35:45 +0000

🏴󠁧󠁢󠁥󠁮󠁧󠁿 English version of this text here!

Volta e meia eu crio aliases que executam comandos com algumas opções que eu uso com frequência. Um deles é o meu alias para git log --oneline.

O problema é que quando eu executo esse comando, vários commits aparecem na minha tela até que ela fique completamente cheia, enquanto que a última linha indica que existem ainda mais commits. Se eu apertar q, eu volto para a minha linha de comando, mas o commit mais recente de todos será empurrado para fora da tela (isso acontece comigo porque o meu prompt ocupa duas linhas).

Além desse problema específico do meu prompt grande, eu normalmente também quero apenas os commits na branch em que estou agora. Uma maneira simples que passou pela minha cabeça seria git log --oneline main..HEAD (ou talvez usando main^). Isso parecia apenas que seria mais um alias pra minha coleção, mas daí eu lembrei que tenho projetos com branch a main e projetos com branch a master.

Decidi, então, praticar minhas habilidades de shell script e fazer um programinha que decidiria automaticamente entre usar main ou master.

Primeiramente

Antes de começar, deixe-me planejar tudo que será feito de antemão.

Se eu fosse escrever pseudo código desse script ou resumí-lo em passos, como seria?
Além disso, o que deveria acontecer se eu não estiver em um repositório git?
Vamos pensar sobre essas coisas enquanto escrevemos um plano:

Temos que:

Imprimir alguma mesangem de erro e sair com código não zero caso não estejamos em um repo git
Descobrir se ou main ou master estão disponíveis
Executar git log main^/master^..HEAD se possível
Imprimir alguma mensagem de erro e sair com código não zero caso contrário

1 - Verificar se estamos em um repositório git

Uma maneira simples, e não muito boa, seria de apenas executar ls .git. Se sair 0, estamos num repositório git. Se não, não estamos.

Essa não é uma solução muito boa porque não vai funcionar se estivermos dentro de um subdiretório de um repositório git. Temos que pensar em outra forma. Torcemos para que o git já tenha uma maneira simples e fácil de verificar isso.

E certamente tem, já que o git é tão legal.

Uma pesquisa rápida no google me mostrou que o comando git rev-parse --git-dir pode ser usado para isso. man git rev-parse mostra mais detalhes, e a opção --git-dir realmente parece uma boa opção. Quando não estamos em um repositório git, um erro será impresso na tela e um código não zero será retornado, segundo o manual.

Eu não estou realmente interessado na mensagem de erro, apenas no código de saída (zero ou não zero).

Portanto, para verificar se estamos ou não em um repositório git ao mesmo tempo que escondemos mensagens de erro, eu fiz assim:



#!/bin/sh

if [ ! "$(git rev-parse --git-dir 2> /dev/null)" ]; then
  echo Not in a git repository
  exit 1
fi

A sintaxe [ ... ] é uma forma reduzida do comando test.
O ! vai inverter a verificação, isto é, se o comando (nesse caso git rev-parse --git-dir) retornar 0, então ele será considerado "falso" ou que resultou em uma "falha".
O 2> /dev/null está redirecionando a mensagem de erro para /dev/null. Isso é uma maneira simples de apenas não mostrar mensagens de erro na tela.

Então basicamente o que isso está fazendo é verificando se o comando falhou. Se sim, significa que não estamos num repositório git, então uma mensagem de erro é impressa e o script retorna 1. Do contrário, nada acontece e podemos seguir para os nossos próximos passos.

2 - Descobrir se main ou master existem

Podemos fazer isso usando o comando git branch e o comando grep, mas git rev-parse também pode fazê-lo.

A segunda opção é bastante simples, git rev-parse --verify <nome-da-branch> é o suficiente (passe -q para suprimir mensagens de erro):



git rev-parse -q --verify main

Pra mudar um pouco, porém, vou fazer com o grep. Dessa forma, podemos aprender um pouquinho mais sobre regexes!

O comando git branch mostra todas as branches disponíveis na sua máquina local, com a branch atual sendo precedida por um *.

Basicamente podemos usar o grep passando main ou master.

Existe um perigo, porém. Simplesmente executar:



git branch | grep main

vai retornar com sucesso se alguma branch contendo a palavra main existir.

Para resolver esse problema, podemos usar uma expressão regular melhor do que apenas main. O padrão que buscamos é:

Começo da linha
Possivelmente um *, mas poderia não ter também
Espaços em branco (a quantidade depende se um * estava lá ou não)
A palavra main (ou master) exatamente
Final da linha

Vamos fazer por partes:

O regex para o começo da linha é ^
Nos regexes, um * é um quantificador, que significa "a coisa antes de mim entre 0 e infinitas vezes". Portanto, para encontrar literalmente um *, temos que escapá-lo: \*. Além disso, para tornálo opcional, podemos usar o quantificador ?, que significa "a coisa antes de mim entre 0 e 1 vezes". Portanto, o regex pra isso tudo seria \*?
Espaços em branco poderiam simplesmente ser um espaço ou \s. Este último também encontra coisas como tabulações e quebra de linhas. Como a quantidade de espaços pode variar, podemos usar o quantificador *, resultando em \s*
As palavras main ou master podem ser encontradas pelas palavras literais
O regex para o final de uma linha é $

Portanto, nosso regex para a branch main seria ^\*?\s*main$. Para a master, é claro, é extremamente similar.

Um ponto importante, apra usar alguns caracteres especiais no regex, o comando grep deve ser invocado com a flag -E (a opção de regex extendido)!

O comando final para a branch main, então, poderia ser:



git branch | grep -E '^\*?\s*main$'

Isso deve funcionar para nós.

3 - Executar git log para a branch correta

Podemos fazer isso com uma sequência de comandos if/elif. Se main existir, usamos main. Se não, porém master existir, usamos master.

Até poderíamos guardar o resultado do comando acima (git branch com grep) em uma variável e verificá-la. Dessa forma não teremos que executar git branch duas vezes. Porém, também podemos passar diretamente o comando inteiro para o if, assim:



if [ "$(git branch | grep -E '^\*?\s*main$')" ]; then
  git log main^..HEAD
  exit 0
elif [ "$(git branch | grep -E '^\*?\s*master$')" ]; then
  git log master^..HEAD
  exit 0
fi

Esse trecho é razoavelmente simples. É verificado se main existe usando aquele regex que definimos. Se existir, usamos o git log no range saindo de main (incluída, pois adicionamos o ^) até HEAD. Daí saímos 0 para finalizar o script (essa saída 0 provavelmente não é necessária e nem muito boa, pois se existir algum bug em nossa lógica/regex, o programa pode falhar silenciosamente, retornando 0 apesar de um erro!)

4 - Imprimir mensagem de erro e sair não zero caso main/master não sejam encontradas

Podemos simplesmente adicionar um comando else para o trecho acima:



if [ "$(git branch | grep -E '^\*?\s*main$')" ]; then
  git log main^..HEAD
  exit 0
elif [ "$(git branch | grep -E '^\*?\s*master$')" ]; then
  git log master^..HEAD
  exit 0
else
  echo 'Neither main nor master branch found'
  exit 2
fi

Mas funciona?

Podemos testar nosso script agora! (:

Eu salvei um arquivo chamado git-log-main-master com nosso script e dei a ele permissão de execução. Vamos testá-lo:

Isso foi legal. Mas será que não conseguimos fazê-lo melhor?

E se pudéssemos passar flags do git log para nosso script?

Flags!

Isso é bastante simples de se fazer. Em um shell script, a variável especial $@ contém todos os argumentos passados ao script, então podemos simplesmente adicioná-lo às nossas linhas com "git log":



if [ "$(git branch | grep -E '^\*?\s*main$')" ]; then
  git log main^..HEAD "$@"
  exit 0
elif [ "$(git branch | grep -E '^\*?\s*master$')" ]; then
  git log master^..HEAD "$@"
  exit 0
else
  echo 'Neither main nor master branch found'
  exit 2
fi

Agora se passarmos um monte de flags, será executado o git log com essas opções:

Mas será que não podemos tornar esse script ainda mais legal de usar? E se passássemos um nome de uma branch pra usar ao invés de main ou master?

Isso com certeza pode ser feito. Quem sabe pudéssemos assumir que o primeiro argumento é ou um nome de branch ou uma flag, e usar as variáveis posicionais especiais $1, $2 etc.

Talvez o comando pudesse ser git log $1^..HEAD $FLAGS, onde $FLAGS seriam todos os argumentos passados menos o primeiro.

Isso envolveria um tratamento melhor e verificações pra ver se todos os argumentos passados são somente flags (daí poderíamos manter main/master e $@) ou se um nome de branch foi passado. É certamente factível, mas vou deixar a possibilidade pra outro post por enquanto... 😅

Aliases...?

Como eu disse, costumo fazer aliases para comandos simples com flags que uso comumente. --oneline é definitivamente uma das minhas opções mais usadas com git log, e é claro, eu fiz um alias:



alias gl='~/scripts/git-log-main-master --oneline'

Script no final das contas



#!/bin/sh

##############################

# Non zero exit codes:

#   1 - If not in a git repository

#   2 - If neither git branch main nor master is found

##############################

if [ ! "$(git rev-parse --git-dir 2> /dev/null)" ]; then

  echo Not in a git repository

exit 1

fi

if [ "$(git rev-parse -q --verify main)" ]; then

  git log main^..HEAD "$@"

exit 0

elif [ "$(git rev-parse -q --verify master)" ]; then

  git log master^..HEAD "$@"

exit 0

else

  echo 'Neither main nor master branch found'

exit 2

fi

Isso é tudo por hoje

Ainda estou aprendendo o básico de shell script, e deve haver maneiras melhores de se fazer isso. Qualquer comentário e sugestão é mais do que bem vindo! 😊

How to only show commits of current branch

Lucas Perez — Mon, 04 Oct 2021 18:33:14 +0000

🇵🇹 Versão em português desse texto aqui!

Every now and then I make aliases that execute a command with a few flags that I use often. One of them being an alias for git log --oneline.

The problem is that when I executed this command, it would show all the commits untill my screen is filled, and the last line shows that it has more to come. If I press q, I will return to my prompt, but the most recent commit will be pushed out of my screen (because my prompt has two lines).

Other than this specific problem to my big prompt, I usually just want the commits on the branch I am right now. A simple way that crossed my mind was git log --oneline main..HEAD (or maybe use main^). This looked like a simple new alias for my collection, but then I remembered that I have projects with a main branch and also other projects with a master branch.

I decided, then, to practice my shell scripting and make a script that would decide between main or master automatically.

First things first

Before starting, let me plan what will be done beforehand.

If I would write some pseudo code of this script or summarize it in steps, how would that be?
Also, what should happen if I am not in a git repository?
Let's think about these things while writing down a plan:

We have to:

Print some error message and exit non zero code if not in a git repository
Find out if either main or master branch is available
Execute git log main^/master^..HEAD if possible
Print some error message and exit non zero code otherwise

1 - Check if in a git repository

A simple, and not very good, way would be to just execute ls .git. If it exits 0, we are in a git repo. If not, then we are not.

This is not a very good solution because it will not work if we are inside a subdirectory of a git repository. We have to think about something else, but hopefully git itself already has some quick way to check this.

And surely it has, since git is so nice.

A quick google search showed me that the command git rev-parse --git-dir can be used for this task. man git rev-parse shows more details, and the --git-dir option indeed looks like a good option. When we are not in a git repo, it prints an error message and exits "non zero", according to the manual.

I'm not really interested in the error message, just the exit code (zero or non zero).

So to check if we are in a git repository while also hiding possible error messages, I did this:



#!/bin/sh

if [ ! "$(git rev-parse --git-dir 2> /dev/null)" ]; then
  echo Not in a git repository
  exit 1
fi

The [ ... ] syntax is a shorthand for the test command.
The ! will invert the check, if the command (in this case, git rev-parse --git-dir) returns 0, then this will be considered "false", or a "failure".
The 2> /dev/null is redirecting the error message to /dev/null. This is a simple way of not showing error messages.

So basically what this is doing is checking if the command failed. If it did fail, it means we are not in a git repo, so an error message is printed and the script returns 1. If the command succeeds, nothing happens, and we can proceed to our next steps.

2 - Find out if main or master exists

We can do this using the git branch command and some grepping, but git rev-parse can also do it.

The second option is very simple, git rev-parse --verify <branch-name> will do the trick (pass -q to hide error messages):



git rev-parse -q --verify main

Just for a change, though, I'll use the simple (maybe naive) grep way. By doing so, we can learn more about regexes!

The command git branch shows all the branches you have avaiable in your local machine, with the current branch being preceded by a *.

Basically we can grep for main or master.

There is a danger, though. Simply executing:



git branch | grep main

will return successfully if any branch containing the word main exists.

To solve this problem, we can use a better regular expression than just main. The pattern we are looking for is:

Start of the line
Possibly a *, but could not have it
Whitespaces (the amount depends if a * was there or not)
The word main (or master) exactly
End of the line

Let's break down how to do each part:

The regex start of the line token is ^
In regex, a * is a quantifier, meaning "the thing before me between 0 and unlimited times", so to match the * literal, we have to escape it: \*, and to make it optional, we use the ? quantifier (it means "the thing before me between 0 and 1 times"). So to match a possible *, the regex would be \*?
Whitespaces can be simply a space or \s, the latter matching things like tabs and new lines also. The amount of whitespaces can vary, so we can use the * quantifier, leaving us with \s*
The words main or master can be matched with the literal words
The end of the line is the token $

So our regex would be ^\*?\s*main$ for the main branch. For the master, of course, is extremely similar.

An important note, to use some special regex characters, grep have to be invoked with the -E flag (the extended regex flag)!

The command for the main branch could then be:



git branch | grep -E '^\*?\s*main$'

This should work for us right now.

3 - Execute git log for the correct branch

We can do this with a sequence of if/elif commands. If the main exists, use it. If not, but the master exists, use master instead.

We could store the result of the last step in a variable and check it, or we could just check it directly:



if [ "$(git branch | grep -E '^\*?\s*main$')" ]; then
  git log main^..HEAD
  exit 0
elif [ "$(git branch | grep -E '^\*?\s*master$')" ]; then
  git log master^..HEAD
  exit 0
fi

This snippet is fairly simple. It checks if main exists using the regex we defined. If it does, it git logs the range from the main (inclusive, since we added ^) to HEAD. It then exits 0 to finish the script (this exit is probably not needed and also not very good, because if there is some bug in our logic/regex, it can fail silently, exiting 0!).

4 - Print error message and exit non zero if main/master not found

We can simply add an else statement to the snippet above:



if [ "$(git branch | grep -E '^\*?\s*main$')" ]; then
  git log main^..HEAD
  exit 0
elif [ "$(git branch | grep -E '^\*?\s*master$')" ]; then
  git log master^..HEAD
  exit 0
else
  echo 'Neither main nor master branch found'
  exit 2
fi

Does it work?

We can test our script now! (:

I saved a file named git-log-main-master with our script and gave it execution permission. Let's try it out:

Now that's nice. But can we make it better?

What if we could pass the standard git log flags to it?

Flags!

This is fairly simple to do. In a shell script, the special variable $@ contains all the arguments passed to the script, so we can simply append it to our "git log" lines:



if [ "$(git branch | grep -E '^\*?\s*main$')" ]; then
  git log main^..HEAD "$@"
  exit 0
elif [ "$(git branch | grep -E '^\*?\s*master$')" ]; then
  git log master^..HEAD "$@"
  exit 0
else
  echo 'Neither main nor master branch found'
  exit 2
fi

Now if we pass a bunch of flags, it is going to execute git log with those options:

Is there a way to make it even nicer to use? What if we passed a branch name to use instead of either main or master?

We could definitely do that. Maybe we could assume the first argument is either a branch name or a flag and use the positional special arguments $1, $2 etc.

Maybe the command could be git log $1^..HEAD $FLAGS, where $FLAGS would be all the arguments passed but the first.

This would involve some better treatment and checks to see if all the arguments are just flags (in this case we could keep main/master and $@) or if a branch name was passed, and is definitely doable, but I'll leave for possibly another post for now... 😅

Aliases...?

Like I said, I usually make aliases for simple commands with common flags. --oneline is definitely one of my most used options for git log, and sure enough, I made an alias:



alias gl='~/scripts/git-log-main-master --oneline'

Summed up script



#!/bin/sh

##############################

# Non zero exit codes:

#   1 - If not in a git repository

#   2 - If neither git branch main nor master is found

##############################

if [ ! "$(git rev-parse --git-dir 2> /dev/null)" ]; then

  echo Not in a git repository

exit 1

fi

if [ "$(git rev-parse -q --verify main)" ]; then

  git log main^..HEAD "$@"

exit 0

elif [ "$(git rev-parse -q --verify master)" ]; then

  git log master^..HEAD "$@"

exit 0

else

  echo 'Neither main nor master branch found'

exit 2

fi

That's it for today

I'm still learning the very basics of shell scripting, and there are probably better ways of doing this. Any comment and advice is more than welcome! 😊

Open all conflicted files from Command Line

Lucas Perez — Wed, 28 Apr 2021 00:07:39 +0000

A few days ago I learned more about the xargs command.

For a brief explanation, xargs will receive a chunk of text and transform it in a list of arguments and pass it to a command that you can specify.

For instance, if you write in the terminal:

echo -e "file1\nfile2"

You will see this result:

file1
file2

We now could pipe this into xargs and do something with it, say, create files with those names:

echo -e "file1\nfile2" | xargs touch

We just created two files whose names are file1 and file2.

There are many things you could do with xargs, write xargs -h to see more (the -I flag is specially interesting).

But what happened today was that I decided I wanted to open all files that had a conflict after an attempted git rebase -i command.

To do that, we first have to find a way to list all the files with a conflict. I'm pretty sure there is nothing git can't do, and of course what we want is very possible.

The command git diff can receive the flag --name-only, which will give you just the names of the files that git diff would have looked at.

user@pc:~$ git diff --name-only
app/this-guy
config/this-other-guy
user@pc:~$

This is just what we wanted! We can now easily pipe it into xargs and call a code editor, for example vim:

git diff --name-only | xargs vim

Xargs can be very useful, this is just one use case. Maybe you want to append a specific extension to a bunch of files? You could use find, ls and grep, just to pass them to xargs with a mv command, for instance.

I hope someone else also learns a little with my little "playing around in terminal" thing.

Thanks for reading and have a nice day (:

Verificando parênteses, colchetes e chaves correspondentes com Elixir

Lucas Perez — Thu, 08 Apr 2021 00:28:33 +0000

🏴󠁧󠁢󠁥󠁮󠁧󠁿 English version of this text here!

Eu comecei a estudar a linguagem Elixir e decidi resolver alguns exercícios de programação pra conseguir entender melhor alguns conceitos.
Como eu acabei gostando da minha solução, decidi fazer esse post explicando o pensamento por trás dela. Sugestões pra melhorar ainda mais o código ou pra melhor seguir os padrões e convenções do Elixir são mais do que bem-vindos! (:

O Problema

Quero fazer uma função que recebe uma string de entrada, supostamente uma expressão matemática ou um trecho de código, e que me diga se todos os seus abre parênteses/colcehetes/chaves são corretamente fechados.
Algumas expressões de exemplo:

1 * 2 (3 + [4 / 5])
# deveria retornar true
9 / [(8 + 7] - 6)
# deveria retornar false

Faça um plano

Antes de começar a escrever código, eu acho que é uma boa ideia resolver o problema de maneira teórica, para aí sim tentar implementá-lo.

Pra esse exercício, eu acredito que usar o conceito de pilha seja uma boa ideia.
Basicamente, uma pilha é um conjunto de itens que tem duas operações: push e pop.

O push vai colocar um novo item no conjunto
O pop vai remover o último item adicionado

Ou seja, a pilha segue o princípio do "Last In, First Out" (LIFO), ou seja, "o último a entrar será o primeiro a sair".

Mas como podemos usar uma pilha aqui? Bom, minha solução teórica seria de iterar sobre todos os caracteres na string de entrada e:

Se for uma "abertura" ((, [ ou {), colocamos na pilha
Se for um "fechamento" (), ] ou }), temos que verificar o último item adicionado na pilha. Se forem correspondentes (( com ), por exemplo), nós removemos ele da pilha (pop) e seguimos a iteração. Do contrário, a string de entrada era inválida
Se for outra coisa, ignoramos

Se iterarmos sobre a expressão inteira e nunca acharmos um erro, isso significa que todos os fechamentos tiveram uma abertura apropriada, mas isso não significa necessariamente que a string era válida. Veja esse exemplo:

1 + (2 * [3]

Aqui, todos os fechamentos tiveram uma abertura correta, mas nem todas as aberturas foram fechadas.
Isso significa que, caso sobrevivamos à iteração, temos que verificar também se no final a nossa pilha está vazia. Se sim, então todas as aberturas foram corretamente fechadas. Se não, o valor de entrada era inválido.

A Implementação

Boa, temos um plano. Agora, temos que traduzir isso para Elixir.
Pra começar, vou criar um módulo chamado Parens com a função check, que vai receber uma string.
Essa função check terá que iterar sobre todos os caracteres desse valor de entrada, então podemos separar essa string usando a função split/2, do módulo String. Nosso primeiro trecho de código então é algo assim:

defmodule Parens do
  def check(expression) do
    expression
    |> String.split("")
  end
end

Usei aqui o operador pipe |>. O que ele faz é que ele usa o que vem antes como o primeiro argumento do que vier depois. Nesse caso, expression será o primeiro argumento para String.split.
O segundo argumento nesse caso é uma string vazia, o que significa que vamos separar expression em todos os caracteres.
O resultado final será uma lista, tipo assim:

"a + b * (c / d)" |> String.split("")
# ["", "a", " ", "+", " ", "b", " ", "*", " ", "(", "c", " ", "/", " ", "d", ")", ""]

Na nossa solução teórica, todos os caracteres diferentes de aberturas/fechamentos deveriam ser ignorados. Podemos removê-los da nossa lista agora usando um filter (filtro). Pra fazer isso, podemos chamar Enum.filter/2, que recebe dois argumentos.
O primeiro deve ser algo "enumerável", que significa que deve ser algo que implementa o "protocolo" Enum.
Felizmente, listas fazem isso, então podemos usar nosso resultado como primeiro argumento do filtro.
O segundo argumento é uma função que recebe um elemento da nossa lista e decide se ele deveria ou não estar no resultado filtrado. Mais especificamente, essa função vai retornar um valor, e se ele for falsy (false ou nil), o filtro vai remover esse item do resultado final. Do contrário, ele vai estar na lista resultante.

No nosso caso, essa função vai ter que verificar cada elemento e dizer se ele é ou uma abertura ou um fechamento, que são os únicos caracteres que nos importam. Uma maneira de se fazer isso é assim:

fn x -> x in ["{", "[", "(", "}", "]", ")"] end

Essa função anônima vai receber algo (x) e ver se essa coisa pertence ou não àquela lista especificada, que contém somente os caracteres importantes (aberturas e fechamentos).
Também poderíamos usar a notação de captura, assim:

&(&1 in ["{", "[", "(", "}", "]", ")"])

Essa notação é parecida, mas ao invés de declarar o x, a gente usa &1, &2, &3... para todos os argumentos que podem chegar.

Beleza, então nosso código até aqui está assim:

defmodule Parens do
  def check(expression) do
    expression
    |> String.split("")
    |> Enum.filter(&(&1 in ["{", "[", "(", "}", "]", ")"]))
  end
end

O próximo passo é iterar sobre nossa listra resultante (depois do filtro) e usar a nossa estratégia da pilha.
Pra fazer isso, decidi criar uma função privada chamada iterate, onde vou recursivamente andar sobre nossos elementos, levando a pilha de um lado para o outro, até termos verificado todos os nossos elementos.
Já que eu vou precisar da pilha, essa função terá uma aridade de 2, ou seja, ela terá 2 argumentos.
A primeira coisa que eu faço quando estou pensando sobre recursão é de escrever a condição de parada. Nesse caso, a função deveria parar assim que a nossa lista de caracteres estiver vazia.
Vou usar a funcionalidade maravilhosa de pattern matching aqui pra fazer isso:

defp iterate([], stack), do: stack

Isso significa que essa função só vai ser executada quando o primeiro elemento for uma lista vazia, e o segundo elemento pode ser qualquer coisa aqui (que será colocado numa variável chamada stack, que significa pilha em inglês).
Nesse caso, a função não está fazendo nada, apenas retornando a pilha. Mais tarde podemos verificar se ela está vazia ou não.

Um ponto muito importante pra perceber aqui é que também temos que passar a pilha quando chamamdos a função iterate pela primeira vez. Nossa pilha começa vazia, então nossa pipeline ficou assim:

def check(expression) do
  expression
  |> String.split("")
  |> Enum.filter(&(&1 in ["{", "[", "(", "}", "]", ")"]))
  |> iterate([])
end

Obs: Também podemos usar um valor padrão aqui, mas deixarei assim.

Agora, a parte difícil. Depois de escrever a condição de parada da nossa recursão, temos que escrever o passo recursivo (ou passos).

Vamos relembrar nosso plano outra vez. Temos que olhar pra cada elemento, e se for uma abertura, colocamos na pilha e seguimos em frente. Vamos fazer essa parte primeiro.

Eu amo pattern matching, então vou estar usando aqui de novo. E pra ajudar-nos ainda mais, também usarei algumas guardas (ou guard, em inglês), pra decidir se a função será executada ou não:

defp iterate([head | tail], stack) when head in ["{", "[", "("] do
end

Essa função somente será executada se a variável head estiver naquela lista de aberturas. Mas de onde essa variável está vindo?
Estamos fazendo o pattern matching do primeiro argumento com [head | tail], então essa função vai precisar que o primeiro argumento seja uma lista que tenha um primeiro elemento. Esse elemento então vai ser vinculado/ligado (bind) a head. O resto da lista será vinculado a tail. Sempre que estiver em dúvida, podemos abrir o shell interativo do Elixir e fazer alguns testes.
Escreva iex no terminal e aperte enter, e tente alguns códigos como esses:

[head | tail] = [1,2,3,4]
head
#=> 1
tail
#=> [2,3,4]

[head2 | tail2] = [0]
head2
#=> 0
tail2
#=> []

[head3 | tail3] = []
# Vai levantar um "matching error"!

Os conceitos de "cabeça" e "cauda" de uma lista são bastante importantes (head e tail, respectivamente). O primeiro elemento de uma lista é sua cabeça, e a cauda será o resto da lista. Perceba que a cauda é também uma lista!

Okay, de volta pra nossa função. O que ela deveria fazer se o elemento sendo verificado for uma abertura?
Ela deveria colocar na pilha (push) e seguir iterando. Podemos fazer isso simplesmente chamando iterate com os argumentos certos.
Como já verificamos o primeiro elemento, temos que passar a lista sem o primeiro elemento, certo? E isso é exatamente o que tail é! Ótimo, mas como podemos adicionar (fazer o push) esse elemento na pilha?
O Elixir oferece uma maneira muito fácil de colocar um item no começo de uma lista, e é simplesmente assim:

[elemento_novo | pilha]

Isso é uma lista cuja cabeça é elemento_novo, e a cauda é pilha. Sempre podemos ir no iex e fazer alguns experimentos:

[1 | 9,8,7]
#=> [1,9,8,7]

Então, nossa função pode ficar meio assim:

defp iterate([head | tail], stack) when head in ["{", "[", "("],
  do: iterate(tail, [head | stack])

Quando head for uma abertura, a gente chama iterate passando tail como primeiro argumento e a pilha com um novo elemento adicionado como segundo elemento.

Legal! Agora que temos essa parte feita, vamos recapitular:

Já sabemos parar a recursão;
Já lidamos com os casos dos caracteres que não são nem aberturas, nem fechamentos;
Já sabemos adicionar um item na pilha e seguir adiante;

Agora temos que fazer alguma coisa quando o elemento é um fechamento. Quando isso acontece, a ideia era olhar o último item adicionado na nossa pilha, que por construção, vem a ser exatamente a cabeça da nossa pilha!

A próxima parte do código foi fortemente refatorada, mas eu vou mostrar como eu fiz inicialmente.

Pra cada fechamento possível, eu fiz uma declaração específica, fazendo o pattern match na cabeça dos elementos que vão ser iterados, assim:

defp iterate(["}" | tail], stack)
defp iterate(["]" | tail], stack)
defp iterate([")" | tail], stack)

E daí pra cada uma delas, eu fiz um if/else simples:

defp iterate(["}" | tail], stack) do
  if hd(stack) == "{" do
    iterate(tail, tl(stack))
  else
    false
  end
end

Primeiro de tudo, aqui eu usei as funções hd e tl, que retornam a cabeça e a cauda de uma lista, respectivamente. Seria a mesma coisa que escrever isso:

defp iterate(["}" | tail], [stack_head | stack_tail]) do
  if stack_head == "{" do
    iterate(tail, stack_tail)
  else
    false
  end
end

Essa função, então, só vai executar se o primeiro elemento da lista for exatamente }. Daí a gente verifica se o último elemento adicionado na pilha, sua cabeça (estamos adicionando as coisas "pela cabeça" na lista!) é {, que seria a correspondência correta.
Se for, temos que fazer o pop desse elemento, era o nosso plano. Perceba que a versão "popada" da pilha é simplesmente sua cauda, então é por isso que não passamos a pilha pra próxima iteração, e sim sua cauda (representada por stack_tail, veja o pattern matching nos argumentos da função).
Se não for a correspondência correta, a gente sabe que a string de entrada não era válida, então estou retornando false aqui.

Note que a parte do else não é realmente necessária, pois se não entrássemos na parte do if, o valor retornado seria nil, mas vou deixar assim por enquanto. Depois podemos refatorar (:

Isso parece uma boa "versão alpha" da nossa função iterate. O que está faltando é verificar no final se a nossa pilha está vazia ou não após a condição de parada.
Poderíamos usar aqui Enum.empty?, que receberia a pilha e verificaria se está vazia ou não (true se estiver vazia, false caso contrário).
Uma outra maneira de fazer isso seria adicionar uma comparação com [] ou na condição de parada, ou na pipeline da nossa função check. Vou fazer a segunda opção primeiro pra poder falar rapidinho do módulo Kernel.

O módulo Kernel tem todas as funções "nativas", que podemos chamar sem escrever um módulo. Ou seja, se você quiser somar dois inteiros, podes fazer dos dois jeitos:

1+2
#=> 3
Kernel.+(1,2)
#=> 3

A comparação == também faz parte do módulo Kernel, então podemos fazer assim:

def check(expression) do
  expression
  |> String.split("")
  |> Enum.filter(&(&1 in ["{", "[", "(", "}", "]", ")"]))
  |> iterate([])
  |> Kernel.==([])
end

Isso vai pegar o que quer que seja que tenha retornado de iterate e passar como primeiro argumento de Kernel.==. O segundo argumento é [], então vamos retornar a comparação entre o resultado de iterate com [].
Se a entrada for uma expressão inválida, iterate pode retornar false, e daí a comparação com [] também será falsa.
Outra possibilidade é que iterate vai retornar uma pilha não vazia, ou seja, uma lista com algum elemento. Neste caso, a comparação com [] também será falsa.

Isso até resolve o problema, mas pra mim é bastante feio.

Pra começo de conversa, às vezes iterate retorna um booleano, mas às vezes retorna uma lista, seja vazia ou não.
Agora que eu já escrevi um pouquinho sobre o módulo Kernel, acho que podemos não utilizá-lo aqui (:
Pra evitá-lo, podemos simplesmente colocar a comparação na nossa condição de parada:

defp iterate([], stack), do: stack == []

Outro jeito é de usar o pattern matching no segundo argumento, também!

defp iterate([], []), do: true
defp iterate([], _stack), do: false

Se o primeiro argumento for uma lista vazia e o segundo, também, retornamos true.
Se o primeiro argumento for uma lista vazia e o segundo for qualquer coisa, retornamos false.
O underline(_) em _stack denota que que essa variável não será usada. Poderíamos escrever simplesmente _, sem a palavra "stack" junto, mas acho que quando não é óbvio o que pode ser esse segundo parâmetro, é uma boa ideia dar um nome melhor para a variável, em nome da legibilidade.

Okay, então isso aparentemente funciona, certo?

Se tentarmos rodar nosso código agora, de vez em quanto tomaremos um erro!
Pra testá-lo, podemos usar nosso módulo dentro do iex. Pra fazer isso, salve o código em um arquivo, por exemplo, parens.ex. Agora, execute iex parens.ex. Conseguimos agora usar o módulo Parens, que criamos, dentro do iex!
Se tentarmos verificar uma string onde um fechamento foi encontrado num momento em que não há nenhuma abertura na nossa pilha, estaríamos tentando pegar a cabeça de uma lista vazia, o que levanta um erro para nós. Podes verificar com esses exemplos:

Parens.check("a}")
#> Levanta um erro!

Parens.check("(a}")
#=> false

Podemos arrumar isso se verificarmos se a pilha está vazia antes de tentarmos pegar a cabeça.

Ou...

Poderíamos simplesmente declarar uma função fazendo pattern matching no segundo argumento para uma lista vazia quando o elemento a ser analisado é um fechamento, assim:

defp iterate([head | _], []) when head in ["}", "]", ")"], do: false

A guarda vai garantir que o elemento em questão é um fechamento, e quando a pilha está vazia, retornamos direto false antes de tentar pegar a cabeça de uma lista vazia (que jogaria um erro em nós).

A primeira versão da nossa solução, portanto, poderia ser isso:

defmodule Parens do
  def check(expression) do
    expression
    |> String.split("")
    |> Enum.filter(&(&1 in ["{", "[", "(", "}", "]", ")"]))
    |> iterate([])
  end

  defp iterate([], []), do: true
  defp iterate([], _stack), do: false

  defp iterate([head | tail], stack) when head in ["{", "[", "("],
    do: iterate(tail, [head | stack])

  defp iterate([head | _], []) when head in ["}", "]", ")"],
    do: false

  defp iterate(["}" | tail], stack) do
    if hd(stack) == "{" do
      iterate(tail, tl(stack))
    else
     false
    end
  end

  defp iterate(["]" | tail], stack) do
    if hd(stack) == "[" do
      iterate(tail, tl(stack))
    else
     false
    end
  end

  defp iterate([")" | tail], stack) do
    if hd(stack) == "(" do
      iterate(tail, tl(stack))
    else
     false
    end
  end
end

Show! Então agora nosso código realmente funciona!
Mas ele não me passa uma vibe muito boa...

Refatoração!

Primeiro, estamos usando listas como ["{", "[", "("], ["{", "[", "("] e ["{", "[", "(", "}", "]", ")"] algumas vezes, que poderiam ser extraídas para atributos de módulo.
Um atributo de módulo é um valor que pode ser usado por qualquer método dentro de um módulo. Pra definí-los, podemos escrever algo como @nome_do_atributo logo em seguida o seu valor.
No nosso caso, podemos fazer algo assim:

defmodule Parens do
  @opener ["{", "[", "("]
  @closer ["}", "]", ")"]
end

Com essa pequena adição, podemos reescrever nossas guardas e nosso filtro, desta maneira:

Enum.filter(&(&1 in ["{", "[", "(", "}", "]", ")"]))
Enum.filter(&(&1 in @opener || &1 in @closer))

defp iterate([head | tail], stack) when head in ["{", "[", "("]
defp iterate([head | tail], stack) when head in @opener,

defp iterate([head | _], []) when head in ["}", "]", ")"], do: false
defp iterate([head | _], []) when head in @closer, do: false

Isso é legal, mas ainda temos 3 grandes funções que são basicamente a mesma coisa, que são as que decidem o que fazer quando o elemento checado é um fechamento.

Vou escrever aqui a maneira como podemos melhorá-las, usando apenas um outro atributo de módulo e uma única função, e vou explicar depois o que ela faz:

defmodule Parens do
  @pairs %{"{" => "}", "[" => "]", "(" => ")"}

  defp iterate([head | tail], [stack_head | stack_tail]) when head in @closer,
    do: @pairs[stack_head] == head && iterate(tail, stack_tail)
end

Primeiro, eu criei o atributo @pairs, que é um mapa. Cada chave desse mapa é um caracter de abertura que é mapeado para o seu caracter de fechamento correspondente (mapas são como hashes e dicionários, se você está vindo do Ruby ou Python).
Então, eu fiz uma outra definição para iterate/2 que tem uma guarda. Essa guarda vai nos assegurar que a variável head (elemento a ser verificado) é um caracter de fechamento (então é ou ), ou ], ou }).
Eu também usei uma operação booleana && aqui:

@pairs[stack_head] == head && iterate(tail, stack_tail)

Se o lado esquerdo dessa operação for falsy, então este valor é retornado e o lado direito não é executado (o que para a nossa recursão).
Se o lado esquerdo for truthy, então seja lá o que for que está do lado direito é retornado. Nesse caso, o lado direito é uma chamada recursiva da nossa própria função iterate, continuando o ciclo.

Agora olhemos para @pairs[stack_head]. Lembra que @pairs é um mapa? Ou seja, se tivéssemos, por exemplo, @pairs["{"], isso retornaria "}".
Se seja lá o que for que estiver na cabeça da nossa pilha for um caracter de abertura, então estamos mapeando-o para o seu respectivo fechador quando consultamos o valor de @pairs[stack_head]. Se esse fechador for o mesmo que está na variável head, então essa comparação retorna true, que fará com que aquela operação booleana retorne o lado direito, isto é, a chamada recursiva da função, passando o resto da lista (tail) e a versão "popada" da pilha (stack_tail).
Se o que estiver na cabeça da pilha não for uma abertura, @pairs[stack_head] vai retornar nil, e nil == head vai ser falso, logo, a recursão morre aí.
Também pode acontecer que o que está na cabeça da pilha é uma abertura, mas @pairs[stack_head] não é igual a head. Logo, a comparação vai ser falsa também. Esse é o caso em que estamos tentando fechar algo que ainda não foi aberto, e como deu falso naquela comparação, a recursão para por aí.

Portanto, isso basta para verificar se os caracteres correspondem e parar a recursão caso contrário.

Então, a nossa segunda versão do programa seria:

defmodule Parens do
  @pairs %{"{" => "}", "[" => "]", "(" => ")"}
  @opener ["{", "[", "("]
  @closer ["}", "]", ")"]

  def check(expression) do
    expression
    |> String.split("")
    |> Enum.filter(&(&1 in @opener || &1 in @closer))
    |> iterate([])
  end

  defp iterate([], []), do: true
  defp iterate([], _stack), do: false

  defp iterate([head | tail], stack) when head in @opener,
    do: iterate(tail, [head | stack])

  defp iterate([head | _], []) when head in @closer, do: false

  defp iterate([head | tail], [stack_head | stack_tail]) when head in @closer,
    do: @pairs[stack_head] == head && iterate(tail, stack_tail)
end

Isso é tudo por hoje

Obrigado por lerem isso. Estou gostando bastante de Elixir! Pattern matching é bastante poderoso e divertido, também.
Por favor, corrijam erros que eu possa ter feito (:
Espero que vocês tenham aprendido algo hoje, e que tenham um bom dia.

Verify matching parens, brackets and braces with Elixir

Lucas Perez — Wed, 07 Apr 2021 19:44:56 +0000

🇵🇹 Versão em português desse texto aqui!

So I've started to study the Elixir language and decided to solve some coding exercise with it in order to better understand some concepts.
Since I liked my solution, I decided to make a post explaining the thought process behind it. Suggestions to further improve the code or to better follow Elixir's conventions are more than appreciated! (:

The Problem

I want to make a function that receives a string as input, supposedly a mathematical expression or some code snippet, and tells me whether all of it's opening parenthesis/brackets/braces have a correct closing match.
Some expressions as examples:

1 * 2 (3 + [4 / 5])
# should return true
9 / [(8 + 7] - 6)
# should return false

Make a plan

Before coding, I think it is a good ideia do solve the problem theoretically, and then try to implement it.
For this exercise, I believe using the stack idea is a very good approach. Basically, a stack is a set of items that have two operations: push and pop.

The push operation will put a new item in the set
The pop operation will remove the last pushed item

So the stack follows the "Last In, First Out" dynamic. When I put an item in the stack, this item will be the first one to get out when I start removing them.

How can we use a stack here? Well, my theoretical solution would be to iterate over all the characters in the input string, and if:

It is an opening char (parens/brackets/braces), put it in a stack
It is a closing char, check the last item in the stack: If it matches, we pop it and continue the recursion. If it doesn't, the input string is not valid
If it is something else, ignore

If the whole input string is iterated and I never found an error, this means that all closers had a matching opener, but it doesn't necessarily means the string is valid. This input is an example:

1 + (2 * [3]

All the closers had a matching opener, but not all the openers were closed. This means that if we survive the iteration, we also have to check if our final stack is empty. If it is, all openers were closed, and the input was valid. If it is not, the input was not valid.

The Implementation

Good, we have a plan, so now we have to translate it into Elixir.
For starters, I'm creating a module Parens with a function check that will receive as input a string.
This function check will have to iterate over the string, so we can use the String module's split/2 function. So we have our first piece of code like this:

defmodule Parens do
  def check(expression) do
    expression
    |> String.split("")
  end
end

I'm using the pipe operator |> here, meaning that whatever comes before it, is going to be the first argument of whatever comes after it. In this case, expression is going to be the first argument of String.split.
The second argument is an empty string so we can split the expression at every character. The result of this is a list, like this:

"a + b * (c / d)" |> String.split("")
# ["", "a", " ", "+", " ", "b", " ", "*", " ", "(", "c", " ", "/", " ", "d", ")", ""]

On our theoretical solution, every character but openers/closers were to be ignored, so we can apply a filter in this resulting list. To do that, we can use Enum.filter/2, which receives two arguments.
The first one is something that "is enumerable", which means that this something must implement the Enum protocol.
Luckly, lists do that, so we can pass our resulting list as the first argument to our filter.
The second argument is a function that receives an element of our list and then decide if it should or shouldn't be in the filtered result. More precisely, if this function returns a falsy value (false or nil), then the element will not be in the resulting filtered list. If it returns a truthy value (anything else), it is going to be in the filtered result.
In our case, this function will verify if each element of our list is a parens/brackets/braces and keep it if it is, removing it otherwise. One way to do that is like this:

fn x -> x in ["{", "[", "(", "}", "]", ")"] end

This anonymous function will receive something (x) and see if it belongs to that list, which happens to be a list with only our parens/brackets/braces.
We could also use the capture notation, like this:

&(&1 in ["{", "[", "(", "}", "]", ")"])

The capture notation is similar, but instead of declaring x, we just use &1, &2, &3... for all of our arguments.

Good, so our code right now looks like this:

defmodule Parens do
  def check(expression) do
    expression
    |> String.split("")
    |> Enum.filter(&(&1 in ["{", "[", "(", "}", "]", ")"]))
  end
end

The next step is to iterate over our resulting list and use our "stack strategy". To do that, I decided to create a private function called iterate, where I'll recursively walk over our elements, passing the stack around, until we checked all of our elements. Since I'll need the stack, this function will have an arity of 2, which means it will have 2 arguments.
The first thing I do when I'm thinking about recursion it to write the stop condition. In this case, it should stop once our list of characters is empty. I'll make use of the wonderful pattern matching functionality to do that:

defp iterate([], stack), do: stack

This means that this function will only execute when the first element is an empty list and the second element is whatever it arrives here.
In this case, this function will do nothing and just return the stack, so we can later verify if it is empty or not.

A very important thing to note here is that we also have to pass a stack when we first call the iterate function. Our stack will start empty, so our pipeline will be like this:

def check(expression) do
  expression
  |> String.split("")
  |> Enum.filter(&(&1 in ["{", "[", "(", "}", "]", ")"]))
  |> iterate([])
end

Note: We could also use a default value, but I'll keep it like this.

Now the hard part. After writing a stop condition to our recursion, we have to write the recursive step (or steps).

Let's check our plan again. We have to look at each element, and if it is an opener, we put it in the stack and go on. Let's do this part first.

I love pattern matching, so I'll be using it here again. And to further help us, I'll also use guards to decide if the function will be executed or not:

defp iterate([head | tail], stack) when head in ["{", "[", "("] do
end

This function will only be executed if the variable head belongs to that list of openers. But where is this variable coming from?
We are pattern matching the first argument with [head | tail], so this function will need for the first argument to be a list with a first element. This first element will be bound to head. The rest of the list will be bound to tail. If you are in doubt, open the interactive elixir shell in your terminal (write iex and press enter) and try this code:

[head | tail] = [1,2,3,4]
head
#=> 1
tail
#=> [2,3,4]

[head2 | tail2] = [0]
head2
#=> 0
tail2
#=> []

[head3 | tail3] = []
# Will raise a matching error!

The head and tail are important concepts. The head is the first element of a list, and the tail is the list itself, but without the first element!

Okay, back to our function. What will it do if the character is an opener? It should push it to the stack and continue iterating. We can do that simply by calling iterate again with the right arguments.
Since we already checked the first element, we can pass the list without the first element. That is precisely what tail is! Good, but how can we push the element to the stack?
Elixir offers a good way to put an item in a list, and it is simply like this:

[new_element | stack]

This is a list which its head is new_element, and its tail is the stack. You can always go to iex and make some experiments:

[1 | 9,8,7]
#=> [1,9,8,7]

So our function looks like this:

defp iterate([head | tail], stack) when head in ["{", "[", "("],
  do: iterate(tail, [head | stack])

When it is an opener, we simply call iterate with tail and pass the stack with a newly pushed head item.

Good! Now that we have this part done, let's check the plan again.

We already know how to stop the recursion;
We already took care of the "ignore if not opener/closer" issue;
We already know how to push an opener to the stack and continue;

We now have to do something when the element is a "closer". When that happens, the idea was to look at the last added item of our stack, which happens to be the head of stack.

This part of the code was heavily refactored, but I'll tell how I did it first time. For each possible closer, which are }, ] and ), I made its single pattern matched function:

defp iterate(["}" | tail], stack)
defp iterate(["]" | tail], stack)
defp iterate([")" | tail], stack)

And for each one of those, I made a simple if/else statement:

defp iterate(["}" | tail], stack) do
  if hd(stack) == "{" do
    iterate(tail, tl(stack))
  else
    false
  end
end

First of all, I used the functions hd and tl, which returns the head and the tail of a list, respectively. It would be the same as this:

defp iterate(["}" | tail], [stack_head | stack_tail]) do
  if stack_head == "{" do
    iterate(tail, stack_tail)
  else
    false
  end
end

Then, since this function will only execute if the element is exactly }, I'm verifying if the last added item in the stack (its head) is {, which would be a match.
If it is, we have to pop it. The "popped" version of the stack is simply its tail, so that's why we don't pass the stack to the next iteration, but rather the stack_tail.
If it doesn't match, we know that the input string is not valid, so I'm returning a false here.

The else part is not really needed, because in order to go inside it, the comparison should be falsy. When that happens, an if statement alone would return nil, but I'll keep it with this else for now. We can refactor later.

This looks like a valid "alpha version" of our iterate function. What is missing is verifying if the stack is empty or not after the stop condition. A way to do that is to add a comparison with [] in the stop condition or in the pipeline of our check function. Enum.empty? would also work, as it does exactly what its name suggests. I'll show the "comparison with []" first because I can talk briefly about the Kernel module.

The Kernel module has all the functions we can use "natively", without calling a module. So if you want so sum two integers, you can do both:

1+2
#=> 3
Kernel.+(1,2)
#=> 3

The == comparison is also part of the Kernel module, so we can do this:

  def check(expression) do
    expression
    |> String.split("")
    |> Enum.filter(&(&1 in ["{", "[", "(", "}", "]", ")"]))
    |> iterate([])
    |> Kernel.==([])
  end

This will take whatever returns from the iterate call and use it as the first argument of Kernel.==. The second argument is [], so we are going to return the comparison of the result of iterate with [].
If the input is invalid, the iterate may return false, and then the comparison with [] will also be false.
Another possibility is that the iterate will return a not empty stack. Then, the comparison with [] will be false as well.
This actually solves it, but for me it is really ugly.

For starters, sometimes iterate returns a boolean, and sometimes it returns a list, which could be empty or not.
Now that I wrote about Kernel a little bit, I think we should not use it in this case (:
To avoid it, we can put this comparison in our stop condition, like this:

defp iterate([], stack), do: stack == []

Another way is to pattern match the second argument as well!

defp iterate([], []), do: true
defp iterate([], _stack), do: false

If the first argument is an empty list and the second argument is also an empty list, we return true.
If the first argument is an empty list and the second argument is anything (the _ denotes that this variable will not be used), we return false.
Note: We could simply use _ instead of _stack, but I think it is nice to put some name to it in the name of readability, since it is not obvious what the second argument could be

Okay, so this apparently works, right?

If we try to run our code now, we are going to sometimes get an error!
To test it, we can use our module inside iex. To do that, save the code in a file, for example, parens.ex. Now, run iex parens.ex. You'll be able to use the Parens module we just created inside iex!
If you try to check a string where a closer would be found before any opener, the code would try to get the head of an empty stack, which raises an error. You can verify it:

Parens.check("a}")
#> Raises error!

Parens.check("(a}")
#=> false

We can fix this by checking if the stack is empty before trying to get its head.

Or...

We could simply pattern match the second argument to empty list when we have a closer, like this:

defp iterate([head | _], []) when head in ["}", "]", ")"], do: false

The guard will ensure that head is a closer, and when the stack is an empty list, we just return false before trying to get the head of an empty list (which raises an error).

The first version of our solution could then be this:

defmodule Parens do
  def check(expression) do
    expression
    |> String.split("")
    |> Enum.filter(&(&1 in ["{", "[", "(", "}", "]", ")"]))
    |> iterate([])
  end

  defp iterate([], []), do: true
  defp iterate([], _stack), do: false

  defp iterate([head | tail], stack) when head in ["{", "[", "("],
    do: iterate(tail, [head | stack])

  defp iterate([head | _], []) when head in ["}", "]", ")"],
    do: false

  defp iterate(["}" | tail], stack) do
    if hd(stack) == "{" do
      iterate(tail, tl(stack))
    else
     false
    end
  end

  defp iterate(["]" | tail], stack) do
    if hd(stack) == "[" do
      iterate(tail, tl(stack))
    else
     false
    end
  end

  defp iterate([")" | tail], stack) do
    if hd(stack) == "(" do
      iterate(tail, tl(stack))
    else
     false
    end
  end
end

Nice! So now our code actually works!
But it doesn't really give me good vibes...

Refactor!

First, we are using lists like ["{", "[", "("], ["{", "[", "("] and ["{", "[", "(", "}", "]", ")"], which could be extracted to module attributes.
Module attributes are values that can be used by any method in a module. To define them, we can write @attribute_name and then its value. We can do it like this:

defmodule Parens do
  @opener ["{", "[", "("]
  @closer ["}", "]", ")"]
end

This is a nice little addition, so now we can rewrite our guards and filter like this:

Enum.filter(&(&1 in ["{", "[", "(", "}", "]", ")"]))
Enum.filter(&(&1 in @opener || &1 in @closer))

defp iterate([head | tail], stack) when head in ["{", "[", "("]
defp iterate([head | tail], stack) when head in @opener,

defp iterate([head | _], []) when head in ["}", "]", ")"], do: false
defp iterate([head | _], []) when head in @closer, do: false

But we still have 3 big functions that are basically the same, which are the ones that decide what to do when the element we are checking is a closer character.
I'll write what I did and then explain it:

defmodule Parens do
  @pairs %{"{" => "}", "[" => "]", "(" => ")"}

  defp iterate([head | tail], [stack_head | stack_tail]) when head in @closer,
    do: @pairs[stack_head] == head && iterate(tail, stack_tail)
end

So first, I created a @pairs module attribute which is a map. Each key of the map is an opener character and it maps to a closer character (maps are like hashes and dictionaries, if you are coming from ruby or python).
Then, I made an iterate/2 function that has a guard. This guard will ensure that head variable (the first element of our list) is a closer (so it is one of ), ] or }).
I also used a && boolean operation here:

@pairs[stack_head] == head && iterate(tail, stack_tail)

If the left side is a falsy value, then this value is returned and the right side is not executed (which stops our recursion).
If the left side is truthy, then whatever is at the right side is returned. In this case, the right side is a function call, continuing the recursion.

Now I'll look at @pairs[stack_head]. Remember that @pairs is a map, so @pairs["{"], for example, returns "}".
If whatever is the head of our stack is an opener, then it maps to some closer (@pairs[stack_head], then, is some closer). If this closer equals to head (the element we are checking itself), then the comparison returns true, which will then return the right side of the &&, continuing our recursion!
If not, then the comparison will return false, and not execute the right side of the &&.
So this is enough to check if the parens are matching and stop the recursion otherwise.

So our second version of the program is:

defmodule Parens do
  @pairs %{"{" => "}", "[" => "]", "(" => ")"}
  @opener ["{", "[", "("]
  @closer ["}", "]", ")"]

  def check(expression) do
    expression
    |> String.split("")
    |> Enum.filter(&(&1 in @opener || &1 in @closer))
    |> iterate([])
  end

  defp iterate([], []), do: true
  defp iterate([], _stack), do: false

  defp iterate([head | tail], stack) when head in @opener,
    do: iterate(tail, [head | stack])

  defp iterate([head | _], []) when head in @closer, do: false

  defp iterate([head | tail], [stack_head | stack_tail]) when head in @closer,
    do: @pairs[stack_head] == head && iterate(tail, stack_tail)
end

That's it for today

Thanks for reading this. I'm enjoying Elixir very much. Pattern matching is quite powerful and fun.
Please correct any mistakes I might have made (:
I hope you learned something today, and have a good day.

Write Your Own Snippets in VSCode

Lucas Perez — Mon, 11 Jan 2021 02:49:02 +0000

Everyone has its own way of learning things. What I know about myself is that little shortcuts often get in the way at the beginning. One example are snippets and VSCode extensions that add those snippets.

What Are Snippets?

Snippets are just a piece of text (or code, in our case), a little extract from something bigger. They are very helpful to avoid repetition. If you constantly have to write a piece of code, you surely thought about copying and pasting a big chunk of boilerplate code (I know I have). Well, those are basically snippets.
Now, wouldn't it be great if we could automate the process of pasting those chunks of code? Like this:

Here I just typed some kind of shortcut and pressed tab, pretty much like auto completion, but for something bigger.

No Need For VSCode Extensions!

I recently started studying React and decided that to be productive I should add some kind of extension full of snippets, just like in the videos I was watching.

The problem is that now my coding environment got full of autocomplete suggestions that would just return a bunch of text. Many shortcuts that I did not know about would sometimes randomly make me pop huge code extracts when I was trying to write something completely unrelated. Snippets that I didn't know their uses. And then I realized that I was overwhelmed with many useful shortcuts that were not meaningful for me at the moment. I did now know why a particular Snippet existed in the first place.

List of all the snippets of a particular extension

If I don't know why a shortcut is useful, it is not useful for me and I shouldn't use it.

Sometimes I think of it like a game. I have to code a certain amount to unlock a particular snippet. I can only use it when I got tired of writing it by hand.

Create Your Own Snippets

VSCode already has by default some snippets, and that is really nice.
But, you can create your own custom Snippets, and it is actually pretty easy!
This has the immediate benefit of only populating your environment with snippets that you know that exist, you know what is it's purpose and how to use them.
Also, it ensures that you really learn the hard way before actually gifting yourself an easy alternative, meaning that you can code anywhere, and not just in your particular computer.
Finally, you can customize them according to specific needs if necessary.

So, How Do We Do It?

Start your VSCode and open the Command Palette (CTRL + SHIFT + P by default) and write snippet to see the options that appears:

Alternatively, you could go to File > Preferences > User Snippets.

You can now create a .json file full of snippets.
You can either create a language specific file, for example:
javascript.json
Snippets defined here will only apply on a javascript document.
Or you can define a global snippet file. The global ones should end with the .code-snippets extension, for example:
my-global-snippets.json.code-snippets.
Since I am learning react, I created a file named
javascriptreact.json
Snippets here will be available in all .jsx file.

Writing the Snippet

To write the snippet you have to give it a name and associate it with an "object" (it is a JSON, after all), like this:



{
  "Snippet Name" : {
    // keys and values here
  }
}

The more important keys are:

prefix: The shortcut that will invoke it (could have many)
body: The code created when invoked
scope: If you created a global snippets file, you can pass languages here, so that it will only be available for those languages. You can ignore this if you created a language specific file
description: You can pass some text that will show up on autocomplete with information about the snippet here. If no description is passed, it will use the snippet's name.

Here is an example that I'm using:



"React Function Component Export" : {
  "prefix" : "fc",
  "body" : [
    "import React from 'react';",
    "",
    "function ${0:$TM_FILENAME_BASE} () {",
    "\treturn (",
    "\t\t<div>",
    "\t\t\t",
    "\t\t</div>",
    "\t);",
    "}",
    "",
    "export default ${0:$TM_FILENAME_BASE};",
    ""
  ]
},

Note that \t is a single tabulation. Also, \n would have worked for new lines and so on

The prefix here is set to fc, so every time I'm inside a .jsx file, writing "fc" and hitting TAB will generate this code. Now that's useful!

It is also worth noting that CTRL + SPACE will also show the "suggestions" of a particular word, including the snippets

You could also pass many prefixes, like this:
"prefix": ["fc", "rfc", "funcomp", "hello"]
Also, the body supports many special characters. In this example:

$0: This is a "tab-stop" and will put the cursor in this position when the snippet is invoked. Passing repeated tab-stops will give you multiple cursors right from start! You could also have more than one tab-stop without using multi-cursors, just use different indexes for them: $0, $1 etc. It is possible to cicle through those different indexed tab-stops after the snippet was invoked with the TAB key
${0:text}: This is a tab-stop that has a initial value of "text"
$TM_FILE_NAME_BASE: This is a variable that will have the name of the file where the snippet was invoked but without it's extension. There are multiple available variables that you can use

We can look for all the available variables and everything else about writing our own snippets at the documentations:
https://code.visualstudio.com/docs/editor/userdefinedsnippets

Project Specific Snippets

Upon creation, you could also specify a snippet to a project, so that it will not be available anywhere else.
Imagine that for a specific project you have to write some particular text/code very often. Maybe some import, or have some kind of class template, who knows.
In those cases it is probably a good ideia to create a project specific snippet.

To do that, you can either open the Command Pallet, search for snippets and choose the New snippet file for [PROJECT NAME] option. It will create a /.vscode folder at the root of the project's directory and put the json there.
You can now determine the:

scope (languages)
prefix (shortcut to invoke) and
body (actual code)

of all the necessary snippets in that file.

VSCode Extensions, again...

Now, don't get me wrong. I know that people work hard and put a lot of love and effort in creating extensions that come with a number of very nice snippets, and I'm not against this. I'm just saying that, specifically when learning a new technology, it is probably a bad idea. You can use one of those extensions to fill the more generic and everyday snippets and customize just a few particular ones, if you want.

And finally...

Have fun!

Customizing your workspace is fun and helps not only at being productive but also at learning better how things work. I hope I helped someone out there with customizing it's own snippets, because that is something that I'm finding particularly useful.
Thanks for reading, and don't forget to check the docs!
https://code.visualstudio.com/docs/editor/userdefinedsnippets

Stay safe 😊