lash status update :: Elmord's Magic Valley

lash status update

2015-05-14 23:42 -0300. Tags: comp, prog, pldesign, lash, life, em-portugues

Faz quase dois meses desde o primeiro commit do lash. O status do projeto é o seguinte:

No decorrer dessa última semana, o parser original, baseado na biblioteca Comparse de parser combinators, foi substituído por um parser descendente recursivo escrito à mão. Os motivos principais para a reescrita foram que a Comparse não mantém informação de linha e coluna dos elementos parseados, aparentemente não tem suporte nenhum a error reporting (o parser simplesmente "backtracka" quando se depara com um erro, até que o parser inicial backtracka e devolve #f), e o parser estava com uns comportamentos estranhos diante de algumas entradas (o que não é culpa da Comparse, mas não tinha por que eu perder tempo debugando se eu já teria que reescrever o parser uma hora ou outra pelos outros motivos citados). O handling de espaços e newlines no parser antigo também estava o caos, enquanto no atual aparentemente tudo funciona como deveria nesse quesito.

O parser novo reconhece quase toda a linguagem prevista para a "release inicial", lança exceções nos pontos certos do código ao encontrar erros de sintaxe (embora as exceções ainda não sejam muito descritiva, mas já é um começo), e armazena a linha e a coluna de cada construção nos nós da árvore sintática (com pequenos erros, mas nada difícil de resolver). O código ainda está meio crude, e tem muita coisa que ainda dá para refatorar (e.g., repetições que estão codificadas como loops explícitos ao invés de uma construção que abstraia a repetição), mas isso vai ir se resolvendo ao longo do tempo. De repente as partes mais abstratas do parser podem até virar uma biblioteca de parser combinators no futuro (com a diferença de que eu estou usando uma struct mutável e exceções ao invés de uma mônada para manter o estado do parser e indicar erros, o que seria meio unusual para uma biblioteca de parser combinators, mas whatever; ninguém disse que seriam parser combinators funcionais).

O parser novo reconhece mais construções do que o resto do shell é capaz de executar (por exemplo, pipelines, redirects, &, &&, ||, $()... em outras palavras, praticamente todas as funções do shell), o que de certa forma é bom, porque me compele a implementar as coisas que faltam. Nos últimos dias o desenvolvimento anda numa taxa mais ou menos ok (para mim), e acho que é mais ou menos realista prever uma release 0.1* mais ou menos funcional para julho. Pelo menos é (mais ou menos) isso que eu espero. Isso é bom, porque em um momento de otimismo em março eu submeti uma proposta de palestra para o FISL sobre o shell e, na vaga possibilidade de ela ser aceita, até lá seria bom o shell estar num estado usável. (Eu submeti a proposta sob a premissa de que se tudo desse errado com o shell e eu fosse aceito era só pedir para tirarem a palestra, mas a essa altura acho que isso não será mais necessário. Tudo isso assumindo que eu seja aceito, o que seria muito doido, na real.)

Comecei a usar a wiki do projeto no GitHub para fazer anotações. O plano que ela venha a conter:

Uma especificação semi-formal da sintaxe e da semântica das construções do shell, discutindo possíveis corner cases e motivações por trás das decisões;
Informações sobre os internals do shell, para facilitar a vida de quem quiser mexer no código;
Discussão de idéias e propostas para o shell;
Uma descrição dos builtins do shell (i.e., a "standard library"), coisa que até agora não foi muito discutida por aqui, mas que é um aspecto importante do shell;
Eventualmente, tutoriais e documentação voltada ao usuário final.

Para editar a wiki é necessário criar uma conta no GitHub, aparentemente, mas acho que podemos conviver com isso. Contribuições são sempre bem-vindas.

Quanto à linguagem do shell, algumas coisas mudaram:

Por ora, troquei a sintaxe da captura de valor de retorno de função de $[...] para ${...}. O motivo é que eu não sei o que fazer com o [, já que existe pelo menos um comando (especificamente, /usr/bin/[) que espera que os caracteres [ e ] on their own não sejam tratados como caracteres especiais. Por outro lado, não me ocorre nenhuma outra situação em que [ e ] sejam usados literalmente no shell, e o comando [ fica meio que obsoleto dado que haverá builtins que provêem a mesma funcionalidade, então não sei. ${...} tem a vantagem de ter mais cara de "captura o valor desse bloco", mas por outro lado toma o lugar do ${var} convencional do (ba)sh, que serve para separar um nome de variável de outros caracteres da redondeza, e que eu não sei que sintaxe atribuir em lash. Pensei em $<var>, mas eu tinha outros possíveis planos para $< (redirecionamento do lendário canal de objetos). Além disso, talvez ${var} seja uma daquelas coisas tradicionais demais para serem mudadas. Opiniões?
A distinção entre array e dicionário provavelmente vai ser atirada pela janela; internamente, um dicionário cujas chaves são todas números inteiros positivos contíguos pode ser representado internamente como um array por performance, mas acho que essa distinção em nível de linguagem é uma distração desnecessária em um shell. Fica a questão da indexação com string vs. expressão numérica (i.e., $var[índice] avalia índice como uma expressão aritmética, ou é necessário escrever algo como $var[$((índice))] para isso? Haveria operadores separados para indexar com expressão numérica vs. string? Será que operações aritméticas no índice são freqüentes o suficiente em scripts para justificar que elas aconteçam por padrão after all?). Tem que ver isso aí.

Durante o desenvolvimento do novo parser eu descobri um "bug" no Chicken que faz com que variáveis criadas com define dentro de um cond sejam declaradas como globais. A galera na mailing list parece ser da opinião de que isso não é um bug e sim uma feature, entretanto. Meanwhile, eu resolvi o problema no lash redefinindo o cond para wrappear as cláusulas em um (let () ...) implícito (o que cria um "scope boundary" que torna as definições locais), e de brinde ainda lançar uma exceção se nenhuma cláusula for verdadeira. Scheme, yay.

Enquanto o lash anda às mil maravilhas, o mestrado vai por água abaixo, mas isso é assunto possivelmente para outro post.

_____

* No momento eu não estou numerando as versões, mas pelo esquema de numeração previsto (<major>.<minor>.<número de commits desde o último update do minor>), estaríamos na versão 0.0.31. Parece bastante, mas é porque eu tenho o hábito de commitar loucamente enquanto estou mexendo no código.

Comentários / Comments (1)

Hacker do mal, 2015-05-15 17:54:10 -0300 #

<request> Cara, não esquece de fazer o *sohqueaocontrario
:DDDD

Elmord's Magic Valley

Computers, languages, and computer languages. Às vezes em Português, sometimes in English.