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

Eu 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 funcionasse diretamente com a árvore de sintaxe abstrata.

Por que isso?

Eu “m perguntando porque, uma vez que descobri que todo compilador lá fora tem uma fase no processo de compilação em que analisa o código-fonte para um AST, era óbvio para mim que algumas ferramentas de programação visual poderiam tirar vantagem disso para dar ao programador maneiras de editar o AST diretamente de forma visual, e também para fazer a viagem de ida e volta da fonte para o nó-gráfico e, em seguida, de volta para a fonte quando necessário.

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

Então , o que estou perdendo?

Comentários

  • ASTs são muito prolixos e não muito convenientes para programação. Eles foram projetados para compiladores, não programadores.
  • en.wikipedia.org/wiki/Structure_editor
  • O que fazer você quer dizer com ” trabalhar diretamente com a árvore de sintaxe abstrata “? Provavelmente, todas as ferramentas baseadas em blocos, como Blockly, estão editando o AST: elas representam as bordas aninhando (ou empilhando, se você preferir ver dessa forma), e o usuário pode editar a árvore (digamos) arrastando e soltando.
  • É ‘ uma ótima pergunta que muitos de nós, que gostam de compiladores, tivemos. Acho que a resposta mais curta é que, se você pudesse fazer isso e torná-lo amigável, as pessoas iriam usá-lo. O único problema é que ‘ sa big ” se “.
  • Você já olhou para Lisp ? ” [É ‘ s] não tanto que Lisp tenha uma sintaxe estranha, mas que Lisp não tem sintaxe. Você escreve programas nas árvores de análise que são geradas no compilador quando outras linguagens são analisadas. Mas essas árvores de análise são totalmente acessíveis aos seus programas. Você pode escrever programas que os manipulam. ”

Resposta

Muitas dessas ferramentas funcionam diretamente com a árvore de sintaxe abstrata (ou melhor, uma árvore direta -uma visualização dele). Isso inclui Blockly, que você “viu, e outras linguagens baseadas em bloco e editores como ele ( Scratch , Pencil Code / Droplet , Snap! , GP , Tiled Grace e assim por diante).

Esses sistemas não mostram uma representação gráfica tradicional de vértices e arestas, por razões explicadas em outro lugar (espaço e também dificuldade de interação), mas eles 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 , artigo , artigo ). Posso garantir a você, ele está trabalhando diretamente com o AST: o que você vê na tela é uma representação exata da árvore de sintaxe, como elementos DOM aninhados (portanto, uma árvore!).

Captura de tela do código Tiled Grace aninhado

Este é o AST de alguns códigos. A raiz é um nó de chamada de método “for … do”. Esse nó tem alguns filhos, começando com “_ .. _”, que por sua vez tem dois filhos, um nó “1” e um nó “10”. O que aparece na tela é exatamente o que o back-end do compilador expõe no meio do processo – é basicamente assim que o sistema funciona.

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

Ele também “serve a viagem de ida e volta da fonte ao gráfico de nós e depois de volta à fonte quando necessário “. Na verdade, você pode ver isso acontecer quando você clica em” Visualização de código “na parte inferior. Se você modificar o texto, será repetido analisado e a árvore resultante renderizada para você editar novamente, e se você modificar os blocos, a mesma coisa acontece com a fonte.


O código do lápis 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, em geral, 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 o árvore de sintaxe abstrata. O que você vê e manipula é uma renderização eficiente de espaço de uma árvore, em muitos casos literalmente o AST que um compilador ou analisador produz.

Resposta

Pelo menos dois motivos:

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

    Os programadores valorizam ter 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 os ajuda a gerenciar melhor complexidade. (Essa é uma razão pela qual muitos programas ammers usam essas fontes pequenas e enormes e telas enormes de 30 “.

    Se tentássemos exibir o AST como um gráfico ou árvore, a quantidade de código que caberia em uma única tela seria muito menor do que quando é representado como código-fonte. Isso é uma grande perda para a produtividade do desenvolvedor.

  2. Os ASTs são destinados à programação do compilador, e não para fácil compreensão pelos programadores. Se você pegasse uma representação AST existente e a exibisse visualmente, provavelmente seria mais difícil para os desenvolvedores entenderem, porque as ASTs não foram projetadas para serem fáceis de aprender para os desenvolvedores.

    Em contraste, o código-fonte geralmente é projetado para ser legível / compreensível pelos desenvolvedores; esse é normalmente um critério crítico de design para o código-fonte, mas não para os ASTs. Os ASTs precisam ser compreendidos apenas 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.

Veja também https://softwareengineering.stackexchange.com/q/119463/34181 para alguns motivos potenciais adicionais.

Comentários

  • ” Em contraste, o código-fonte foi projetado para ser legível / compreensível pelos desenvolvedores ” – contra-exemplo: mais esolangs, Perl, Lisp
  • ” Becaus O código-fonte é uma representação muito mais concisa. “; ” o idioma AST seria um segundo idioma que os desenvolvedores precisam aprender, além do idioma de origem ” – esses são argumentos contra todos os PLs visuais, mas não ajuda a explicar a distinção que preocupa o OP.
  • ” (Isso ‘ é uma razão pela qual muitos programadores usam essas fontes pequenas e enormes e enormes 30 ” telas.) ” – se você precisa de uma tela grande para ver contexto suficiente, talvez ‘ re-codificação? 😉
  • @Raphael Talvez, mas ‘ é menos esforço para gastar dinheiro nisso do que refatorar!
  • @JanDvorak, .. .LISP é um contra-exemplo porque o AST é a linguagem – que é o que lhe dá seu poder expressivo; escrever código LISP que recompila seu outro código LISP é tão fácil quanto escrever código que modifica estruturas de dados LISP padrão … que são exatamente o que o código LISP é escrito . Há ‘ uma razão para ‘ s durar mais de meio século – a família ‘ O design é incomumente expressivo. Go teve que ter suas extensões assíncronas totalmente integradas à linguagem e ao tempo de execução; para Clojure, é ‘ é apenas uma biblioteca. Veja também: Superando as médias .

Resposta

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

  1. As linguagens Lisp são na verdade escritas como AST. O código-fonte do programa é escrito como listas e usado diretamente pelo compilador e / ou interpretador (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 eficazes (ASG) em um nível mais alto de abstração do que a linguagem AST típica de propósito geral.

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *