Tip:
Highlight text to annotate it
X
Outra pergunta nos foruns foi sobre a quantidade de
regras de expressões regulares, ou tokens, para uma linguagem.
A questão básica era algo como: "parace que nunca termina!"
Eu posso imaginar ter que escrever tantas regras de definições de tokens
que eu acabaria entediado antes de terminar tudo.
É isso que acontece no mundo real? Como é, de fato?
Minha resposta para isso é, em certo grau: "não existe bala de prata".
Não existe uma única maneira fácil de codificar informação estruturada --
de trazer ordem para caos.
Mas o que eu posso dizer a você é que é uma tarefa gigantesca, no caso de linguagens do mundo real.
Eu já trabalhei na construção de um lexer e parser, um frontend para a linguagem de programação C.
Para tratar a linguagem de programação C, que tem milhares de detalhes,
nossa lista de definições de tokens tinha 600 linhas de código.
Isso pode parecer muito, se você tiver que escrever tudo de uma vez,
mas no esquema mais amplo das coisas, um programa normal, como o web browser Firefox,
tem vários milhões de linhas de código.
Então, essa lista de expresões regulares, a lista de definições de tokens,
é, de fato, uma minúsula parte de todo o esforço de engenharia de software.
Eu também estive envolvido na criação de um lexer e parser, um interpretador para Java --
Java 1.1, nessa época -- e nossa lista de tokens, nosso arquivo de definições de tokens, tinha 200 linhas de comprimento.
Java é mais regular do que C, nesse sentido, não requer um lexer tão complicado --
você pode me perguntar sobre isso mais tarde.
200 linhas é até mais razoável.
Finalmente, eu acho que em um dos videos, em algum ponto, eu mencionei o jogo de Tetris particular,
no qual eu tive o prazer de trabalhar, e existia uma linguagem de definição de peças
que permitia planejar pentominoes, ao invés das peças normais de Tetris, com 4 lados.
Existia um leitor de definições de peças, que tinha mais ouu menos 90 linhas,
o que é bem menor e mais atrativo.
Mas o modo como você realmente deve pensar sobre isso é mais como, digamos, raciocinar por analogia.
Seria um trabalho muito grande construir uma estrada? Seria um trabalho muito grande construir um sistema de esgotos?
Seria um trabalho muito gtrande pintar um belo quadro?
Sim, mas você faz o trabalho uma vez, e depois você divide o custo entre todos
aqueles que porventura usam essa construção.
Sim, gasta-se muito tempo para pavimentar uma estrada, mas, depois disso, muitas pessoas podem dirigir sobre ela.
Frequentemente, definições de linguagens como C ou Java, ou C#, ou JavaScript --
elas não mudam com frequência, se é que mudam.
Uma vez que você tenha gasto tempo em escrever todas as suas definições de tokens para JavaScript,
mesmo que isso sejam algumas centenas de linhas de código,
você olha para isso, escreve alguns casos de ***, se sente confiante,
faz uma revisão do código, junto com mais alguém, e então, você termina,
e você pode simplesmente usar isso, tirar proveito disso, pelo resto da sua carreira
de desenvolvedor de software.
Portanto, pode ser um pouco árduo escrever uma porção de definições de tokens,
especialmente se várias delas são parecidas,
mas, uma vez que você tenha feito isso, está terminado.