Ferramentas de programação visual, por que eles não trabalham diretamente com o AST?

Encontrei várias ferramentas de programação visual de código aberto, como Blockly e amigos, e outros projetos hospedados no Github, mas não consegui encontrar nenhum que funcione diretamente com a árvore de sintaxe abstrata.

Por que é que?

Estou perguntando porque, uma vez que eu descobri que todo compilador por aí tem uma fase no processo de compilação em que ele analisa o código-fonte em um AST, ficou óbvio para mim que algumas ferramentas de programação visual poderiam tirar proveito disso para dar ao programador maneiras editar o AST diretamente de maneira visual e também fazer a viagem de ida e volta da origem para o gráfico de nós e, em seguida, retornar novamente à origem, quando necessário.

Por exemplo, pode-se pensar que do JavaScript AST Visualizer para uma ferramenta de programação visual JavaSript real, não há muita diferença.

Então, o que estou perdendo?

Muitas dessas ferramentas fazer o trabalho diretamente com a árvore abstrata de sintaxe (ou melhor, a visualização direta de um-para-um dele). Isso inclui Blockly, que você já viu, e os outros idiomas e editores baseados em blocos como ele ( zero , lápis Código / gota , pressão! , GP , Graça Azulejo , e assim por diante).

Esses sistemas não mostram uma representação tradicional de gráfico de vértice e aresta, por razões explicadas em outros lugares (espaço e também dificuldade de interação), mas estão representando diretamente uma árvore. Um nó, ou bloco, é filho de outro se estiver diretamente, fisicamente dentro do pai.

Eu construí um desses sistemas ( Tiled Grace , papel , papel ). Posso garantir, está trabalhando muito diretamente com o AST: o que você vê na tela é uma representação exata da árvore de sintaxe, como elementos DOM aninhados (uma árvore!).

Este é o AST de algum código. A raiz é um nó de chamada de método "para ... do". Esse nó tem alguns filhos, começando com "_ .. _", que possui dois filhos, um nó "1" e um nó "10". O que aparece na tela é exatamente o que o back-end do compilador cospe no meio do processo - é fundamentalmente como o sistema funciona.

Se desejar, você pode pensar nele como um layout de árvore padrão, com as bordas apontando para fora da tela em sua direção (e ocluídas pelo bloco à sua frente), mas o aninhamento é uma maneira tão válida de mostrar uma árvore quanto um vértice diagrama.

Ele também "fará a viagem de ida e volta da origem para o nó-gráfico e, em seguida, voltará novamente à origem quando necessário". De fato, você pode ver isso acontecer quando você clica em "Visualização de código" na parte inferior. Se você modificar o texto, ele será analisado novamente e a árvore resultante renderizada para você editar novamente. Se você modificar os blocos, o mesmo acontecerá com a fonte.

O Pencil Code faz essencialmente a mesma coisa com, neste ponto, uma interface melhor . Os blocos que ele usa são uma visualização gráfica do CoffeeScript AST. O mesmo acontece com os outros sistemas baseados em blocos ou blocos, embora alguns deles não tornem o aspecto de aninhamento tão claro na representação visual, e muitos não tenham uma linguagem textual real por trás deles, então o " árvore de sintaxe "pode ​​ser um pouco ilusória, mas o princípio está lá.

O que você está perdendo, então, é que esses sistemas realmente estão trabalhando diretamente com a árvore de sintaxe abstrata. O que você vê e manipula é uma renderização de uma árvore com economia de espaço, em muitos casos literalmente o AST que um compilador ou analisador produz.

Pelo menos dois motivos:

1. Porque o código fonte é uma representação muito mais concisa. Criar um AST como um gráfico exigiria muito mais espaço visual.

   Os programadores valorizam o máximo de contexto possível - ou seja, ter o máximo de código presente de uma vez na tela ao mesmo tempo. O contexto ajuda a gerenciar melhor a complexidade. (Essa é uma das razões pelas quais muitos programadores usam essas fontes pequenas loucas e enormes telas de 30 ".)

   Se tentássemos exibir o AST como um gráfico ou uma árvore, a quantidade de código que você poderia caber em uma única tela seria muito menor do que quando representada como código-fonte. Essa é uma enorme perda para a produtividade do desenvolvedor.

2. Os ASTs destinam-se à programação de compiladores, não para facilitar o entendimento dos programadores. Se você pegasse uma representação AST existente e a exibisse visualmente, provavelmente seria mais difícil para os desenvolvedores entenderem, porque os ASTs não foram projetados para facilitar o aprendizado dos desenvolvedores.

   Por outro lado, o código fonte geralmente é projetado para ser legível / compreensível pelos desenvolvedores; esse normalmente é um critério de design crítico para o código-fonte, mas não para os ASTs. ASTs só precisam ser entendidos pelos escritores do compilador, não pelos desenvolvedores comuns.

   E, em qualquer caso, a linguagem AST seria uma segunda linguagem que os desenvolvedores precisam aprender, além da linguagem de origem. Não é uma vitória.

Consulte também /software//q/119463/34181 por alguns possíveis motivos adicionais.

O AST típico dos compiladores é bastante complexo e detalhado. A representação gráfica direcionada se tornaria rapidamente difícil de seguir. Mas existem duas grandes áreas de CS onde ASTs são usados.

1. As linguagens Lisp são realmente escritas como AST. O código fonte do programa é escrito como listas e usado diretamente pelo compilador e / ou intérprete (dependendo de qual variante está sendo usada).
2. Linguagens de modelagem, por exemplo, UML, e muitas linguagens específicas de domínio visual usam notações gráficas que são gráficos de sintaxe abstrata (ASG) efetivos em um nível de abstração mais alto do que a linguagem AST típica de uso geral.