ビジュアルプログラミングツール、なぜASTと直接連携しないのですか？

Blocklyや友人などのオープンソースのビジュアルプログラミングツール、およびGithubでホストされている他のプロジェクトをいくつか見つけましたが、抽象構文ツリーで直接機能するものは見つかりませんでした。

何故ですか？

私が尋ねているのは、すべてのコンパイラがコンパイルプロセスにソースコードをASTに解析する段階があることを発見した後、いくつかの視覚的なプログラミングツールがこれを利用してプログラマに方法を与えることができることは明らかだったからですASTを視覚的な方法で直接編集し、ソースからノードグラフへのラウンドトリップを行い、必要に応じてソースに再び戻すこともできます。

たとえば、人は JavaScript AST Visualizerから実際のJavaSriptビジュアルプログラミングツールまで、それほど大きな違いはない。

だから、私は何が欠けていますか？

これらのツールの多くが行う抽象構文木（というか、それを直接一対一の可視化）と直接仕事を。これには、これまでに見てきたBlockly、および他のブロックベースの言語とそのようなエディター（Scratch、Pencil Code / Droplet、Snap！、GP、Tiled Graceなど）が含まれます。

これらのシステムは、他の場所（空間、および相互作用の難しさ）で説明されている理由により、従来の頂点とエッジのグラフ表現を表示しませんが、ツリーを直接表しています。1つのノード、またはブロックは、直接、物理的に親の内部にある場合、別のノードの子です。

これらのシステムの1つを構築しました（Tiled Grace、paper、paper）。確かに、それはASTを直接操作しているのです。画面に表示されるのは、ネストされたDOM要素（つまり、ツリー！）としての構文ツリーの正確な表現です。

これはいくつかのコードのASTです。ルートは、「for ... do」のメソッド呼び出しノードです。このノードには、「_ .. _」で始まるいくつかの子があり、それ自体に「1」ノードと「10」ノードの2つの子があります。画面に表示されるのは、まさにプロセスの途中でコンパイラバックエンドが吐き出すものです。これが基本的なシステムの動作です。

必要に応じて、画面の外を向いているエッジが標準のツリーレイアウトであると考えることができます（そして、それらの前のブロックによって隠されています）。図。

また、「ソースからノードグラフへの往復を行い、必要に応じてソースに戻る」こともあります。実際、下部の[コードビュー]をクリックすると、そのことがわかります。テキストを変更すると、テキストが再解析され、結果のツリーがレンダリングされて再び編集できるようになります。ブロックを変更すると、ソースでも同じことが起こります。

Pencil Codeは、基本的に同じことを行いますが、この時点では、より優れたインターフェイスを備えています。使用するブロックは、CoffeeScript ASTのグラフィカルビューです。他のブロックベースまたはタイルベースのシステムも概してそうですが、それらのいくつかは視覚的表現でネストの側面を非常に明確にせず、多くはそれらの背後に実際のテキスト言語を持たないため、構文ツリー」は少し幻想的かもしれませんが、原理はそこにあります。

あなたが不足しているもの、そして、これらのシステムは本当にということですされている抽象構文木で直接作業。表示および操作するのは、スペース効率の良いツリーのレンダリングです。多くの場合、文字通り、コンパイラまたはパーサーが生成するASTです。

少なくとも2つの理由：

1. ソースコードははるかに簡潔な表現だからです。ASTをグラフとしてレイアウトすると、より多くの視覚的領域が必要になります。

   プログラマーは、できるだけ多くのコンテキストを持つことを賞賛します。つまり、同時に多くのコードを同時に画面に表示します。コンテキストは、複雑さをより適切に管理するのに役立ちます。（それが、多くのプログラマーがこれらのクレイジーな小さなフォントと巨大な30インチ画面を使用する理由の1つです。）

   ASTをグラフまたはツリーとして表示しようとすると、1つの画面に収まるコードの量は、ソースコードとして表される場合よりもはるかに少なくなります。それは開発者の生産性にとって大きな損失です。

2. ASTは、プログラマーが簡単に理解できるようにするためではなく、コンパイラープログラミング用です。既存のAST表現を使用して視覚的に表示すると、ASTは開発者が学習しやすいように設計されていないため、おそらく開発者にとって理解が難しくなります。

   対照的に、ソースコードは、通常ている開発者が理解/読み取り可能であるように設計します。これは通常、ソースコードの重要な設計基準ですが、ASTの基準ではありません。ASTは、コンパイラ開発者のみが理解する必要があり、日常の開発者は理解する必要はありません。

   そして、いずれにせよ、AST言語は、ソース言語に加えて、開発者が学習しなければならない第二言語になります。勝利ではありません。

その他の潜在的な理由については、https：//softwareengineering.stackexchange.com/q/119463/34181も参照してください。

コンパイラーによる典型的なASTは、かなり複雑で冗長です。有向グラフの表現はすぐに理解するのが非常に難しくなります。しかし、ASTが使用されるCSの2つの大きな領域があります。

1. Lisp言語は実際にはASTとして書かれています。プログラムのソースコードはリストとして記述され、コンパイラおよび/またはインタープリタによって直接使用されます（使用されているバリアントによって異なります）。
2. UMLなどのモデリング言語や多くの視覚領域固有の言語は、典型的な汎用言語ASTよりも高い抽象化レベルで効果的な抽象構文グラフ（ASG）であるグラフィカル表記法を使用します。