비주얼 프로그래밍 도구, 왜 AST와 직접 작동하지 않습니까?

Blockly 및 친구들과 같은 여러 오픈 소스 비주얼 프로그래밍 도구와 Github에서 호스팅되는 다른 프로젝트를 찾았지만 추상 구문 트리에서 직접 작동하는 것을 찾을 수 없었습니다.

왜 그런가요?

일단 모든 컴파일러가 컴파일 과정에서 소스 코드를 AST로 구문 분석하는 단계가 있음을 알게되면 일부 시각적 프로그래밍 도구가이를 활용하여 프로그래머에게 방법을 제공 할 수 있다는 것이 분명했습니다. 시각적으로 직접 AST를 편집하고 소스에서 노드 그래프로 왕복 여행을 한 다음 필요할 때 다시 소스로 돌아갑니다.

예를 들어 JavaScript AST Visualizer 에서 실제 JavaSript 비주얼 프로그래밍 도구에 이르기까지 큰 차이가 없다고 생각할 수 있습니다 .

그래서, 내가 무엇을 놓치고 있습니까?

이러한 도구의 대부분은 할 (또는 오히려 그것의 직접 일대일 시각화) 추상 구문 트리와 직접 일을. 즉, 본 적이 Blockly, 그리고 같은 다른 블록 기반 언어와 편집자를 포함 ( 스크래치 , 연필 코드 / 물방울 , 이런! , GP , 타일 그레이스 등).

이러한 시스템은 다른 곳 (공간 및 상호 작용 난이도)으로 설명 된 이유로 전통적인 정점 및 에지 그래프 표현을 나타내지 않지만 트리를 직접 나타냅니다. 한 노드 또는 블록은 다른 노드가 물리적으로 부모 내부에있는 경우 다른 노드의 자식입니다.

이 시스템 중 하나를 만들었습니다 ( Tiled Grace , paper , paper ). AST와 직접 작업하는 것이 매우 중요합니다. 화면에 표시되는 것은 중첩 된 DOM 요소 (트리)와 같은 구문 트리의 정확한 표현입니다.

이것은 일부 코드의 AST입니다. 루트는 "for ... do"메소드 호출 노드입니다. 해당 노드에는 "_ .. _"로 시작하는 일부 하위 요소가 있으며이 하위 노드에는 "1"노드와 "10"노드의 두 하위 요소가 있습니다. 화면에 나타나는 것은 프로세스 중간에 컴파일러 백엔드가 뱉어내는 것입니다. 이것이 기본적으로 시스템 작동 방식입니다.

원하는 경우 가장자리가 화면을 가리키고 앞쪽의 블록으로 가려진 표준 트리 레이아웃으로 생각할 수 있지만 중첩은 트리를 꼭짓점으로 표시하는 유효한 방법입니다. 도표.

또한 "소스에서 노드 그래프로 왕복 여행을 한 다음 필요할 때 다시 소스로 돌아갈 것"입니다. 실제로 하단의 "코드보기"를 클릭하면 이러한 상황이 발생합니다. 텍스트를 수정하면 텍스트가 다시 구문 분석되고 결과 트리가 다시 편집되도록 렌더링되며 블록을 수정하면 소스에서도 동일한 일이 발생합니다.

연필 코드는 본질적 으로 더 나은 인터페이스 와 동일한 기능을 수행합니다 . 사용하는 블록은 CoffeeScript AST의 그래픽보기입니다. 다른 블록 기반 또는 타일 기반 시스템도 전체적으로 큰 부분을 차지하지만 일부 시스템은 시각적 표현에서 중첩 측면을 명확하게 만들지 못하고 실제 텍스트 언어가 없기 때문에 " 구문 트리 "는 약간 현혹적일 수 있지만 원칙이 있습니다.

당신이 놓치고 그렇다면, 이러한 시스템이 정말이다 하는 추상 구문 트리와 함께 직접 작업. 보고 조작하는 것은 공간 효율적으로 트리를 렌더링하는 것으로, 대부분의 경우 말 그대로 컴파일러 또는 파서가 생성하는 AST입니다.

적어도 두 가지 이유 :

1. 소스 코드는 훨씬 간결한 표현 이기 때문 입니다. AST를 그래프로 배치하면 훨씬 더 많은 시각적 부동산이 필요합니다.

   프로그래머는 가능한 한 많은 맥락, 즉 한 번에 많은 코드를 동시에 화면에 표시하는 상을받습니다. 컨텍스트는 복잡성을보다 잘 관리하는 데 도움이됩니다. (많은 프로그래머가이 미친 작은 글꼴과 거대한 30 인치 화면을 사용하는 이유 중 하나입니다.)

   AST를 그래프 또는 트리로 표시하려고하면 단일 화면에 맞출 수있는 코드의 양이 소스 코드로 표시 될 때보 다 훨씬 적습니다. 그것은 개발자 생산성에 큰 손실입니다.

2. AST는 프로그래머가 쉽게 이해하기위한 것이 아니라 컴파일러 프로그래밍을위한 것입니다. 기존 AST 표현을 가져와 시각적으로 표시 한 경우 AST는 개발자가 배우기 쉽도록 설계되지 않았기 때문에 개발자가 이해하기 어려울 수 있습니다.

   반면, 소스 코드는 일반적으로 되어 개발자가 이해할 수 / 읽을 수 있도록 설계; 이는 일반적으로 소스 코드의 중요한 설계 기준이지만 AST의 경우는 아닙니다. AST는 일상적인 개발자가 아니라 컴파일러 작성자 만 이해하면됩니다.

   그리고 어쨌든 AST 언어는 소스 언어 외에 개발자가 알아야 할 두 번째 언어 일 것입니다. 승리가 아닙니다.

몇 가지 추가적인 이유 는 https://softwareengineering.stackexchange.com/q/119463/34181 도 참조 하십시오 .

컴파일러의 일반적인 AST는 다소 복잡하고 장황합니다. 지시 된 그래프 표현은 따라 가기가 매우 어려워졌습니다. 그러나 AST가 사용되는 CS에는 두 가지 큰 영역이 있습니다.

1. Lisp 언어는 실제로 AST로 작성됩니다. 프로그램 소스 코드는 목록으로 작성되며 컴파일러 및 / 또는 인터프리터가 직접 사용합니다 (사용중인 변형에 따라 다름).
2. 모델링 언어, 예를 들어 UML 및 많은 시각적 도메인 특정 언어는 일반적인 범용 언어 AST보다 더 높은 추상화 수준에서 추상 구문 그래프 (ASG)에 효과적인 그래픽 표기법을 사용합니다.