Cyclone: primeiras impressões

Long time no see, dear blog. Depois de vários desvios estou me concentrando de novo no tema da dissertação, até porque falta pouco. E depois de muito suspense o tema é gerenciamento de memória concorrente/paralelo, o que foi bom porque integrou bem dois temas que eu vinha pesquisando em paralelo, com o perdão do trocadilho. Depois, quem sabe, eu escrevo mais sobre o que estou fazendo.

Mas o assunto agora é Cyclone, a linguagem derivada de C mas mais segura (safe). Além das adições necessárias para tornar a linguagem segura, outras coisas interessantes também acabaram entrando na linguagem: polimorfismo paramétrico, pattern matching, tipos-soma mais interessantes (as unions em C são muito ruins), etc.

O gerenciamento de memória é feito principalmente usando regiões, mas de forma mais manual e com menos inferência do que no caso do MLKit. Além das regiões, os ponteiros possuem vários qualificadores para separar os ponteiros que podem ser nulos ou não, os que apontam para um array terminado com um byte 0 (caso das strings) e etc.

Onde entra Cyclone no meu projeto? A plataforma de testes será um compilador para uma linguagem funcional lazy simples, que inclui obviamente um coletor de lixo. Dessa forma será possível observar o comportamento do coletor em situações reais, ao invés de simplesmente gerar grafos de memória aleatórios. E nesse caso o runtime seria feito em Cyclone, como alternativa a usar C para a mesma tarefa. Não existem muitas escolhas aqui: as linguagens funcionais que eu gosto não servem para esse tipo de system programming. Never mind that, o compilador está sendo escrito em Haskell.

Por enquanto só escrevendo alguns programas para me acostumar com a linguagem (Cyclone), mas a maior dificuldade são os ponteiros. Tanto os qualificadores quanto as regiões me fazem parar para pensar em várias decisões que não me ocorreriam se eu estivesse programando em C, pelo menos não inicialmente. Isso é interessante, mas me faz consultar o manual o tempo todo. Os próprios criadores da linguagem já revelaram na lista a possibilidade de simplificar o sistema, que realmente é bem complexo. De certa forma isso reflete a complexidade inerente do gerenciamento de memória, mas a coisa não precisa ser necessariamente assim para o programador. A visão que o programador tem pode ser outra, caindo para o nível mais baixo quando necessário. Esse é um tema interessante que acontece em outros contextos, mas a discussão sobre isso fica para outra vez.