Blockly 및 친구들과 같은 여러 오픈 소스 비주얼 프로그래밍 도구와 Github에서 호스팅되는 기타 프로젝트를 찾았지만 직접 사용할 수있는 도구를 찾을 수 없습니다. 추상 구문 트리입니다.
그 이유는 무엇입니까?
I “m 모든 컴파일러가 컴파일 프로세스에서 소스 코드를 AST로 구문 분석하는 단계가 있다는 사실을 발견하면 일부 시각적 프로그래밍 도구가이를 활용하여 프로그래머에게 편집 할 수있는 방법을 제공 할 수 있다는 것이 분명했습니다. 시각적 인 방식으로 직접 AST를 수행하고 소스에서 노드 그래프로 왕복을 수행 한 다음 필요할 때 다시 소스로 돌아갑니다.
예를 들어 JavaScript AST Visualizer 와 실제 JavaSript 비주얼 프로그래밍 도구에는 큰 차이가 없습니다.
그래서 , 내가 무엇을 놓치고 있습니까?
댓글
- AST는 매우 장황하고 프로그래밍에 그다지 편리하지 않습니다. 프로그래머가 아닌 컴파일러를 위해 설계되었습니다.
- en.wikipedia.org/wiki/Structure_editor
- 무엇을 " 추상 구문 트리로 직접 작업 "을 의미합니까? 틀림없이 Blockly와 같은 모든 블록 기반 도구는 AST를 편집하고 있습니다. 이러한 도구는 중첩 (또는 이러한 방식으로 보는 것을 선호하는 경우 스택)으로 가장자리를 나타내며 사용자는 끌어서 놓기로 트리를 편집 할 수 있습니다.
- ' 컴파일러를 좋아하는 많은 사람들에게 좋은 질문입니다. 짧은 대답은 만약 당신이 이것을 할 수 있고 사용자 친화적으로 만들 수 있다면 사람들이 그것을 사용할 것이라고 생각합니다. 유일한 문제는 ' 큰 " if "입니다.
- Lisp 를 살펴 보셨습니까? " [그것 ' s] Lisp에 구문이 없기 때문에 Lisp에 이상한 구문이있을 정도는 아닙니다. 다른 언어가 구문 분석 될 때 컴파일러 내에서 생성되는 구문 분석 트리에 프로그램을 작성합니다. 그러나 이러한 구문 분석 트리는 프로그램에서 완전히 액세스 할 수 있습니다. 이를 조작하는 프로그램을 작성할 수 있습니다. "
Answer
대부분의 도구는 추상 구문 트리 (또는 직접 일대일 -그것의 시각화). 여기에는 지금까지 본 Blockly와 이와 유사한 다른 블록 기반 언어 및 편집기 ( Scratch , 연필 코드 / 물방울 , Snap! , GP , Tiled Grace 등).
이러한 시스템은 그렇지 않습니다. 다른 곳에서 설명 된 이유 (공간 및 상호 작용 난이도)로 인해 기존의 정점 및 가장자리 그래프 표현을 보여 주지만 직접 트리를 나타냅니다. 한 노드 또는 블록은 물리적으로 부모 내부에 직접있는 경우 다른 노드의 자식입니다.
이러한 시스템 중 하나를 구축했습니다 ( Tiled Grace , 종이 , 종이 ). 장담 할 수 있습니다. AST와 직접적으로 작업하고 있습니다. 화면에 표시되는 것은 중첩 된 DOM 요소 (즉, 트리!)로 구문 트리를 정확하게 표현한 것입니다.
일부 코드의 AST입니다. 루트는 “for … do”메소드 호출 노드입니다. 이 노드에는 “_ .. _”로 시작하는 몇 가지 자식이 있으며, 자체에는 “1”노드와 “10”노드라는 두 개의 자식이 있습니다. 화면에 나타나는 것은 컴파일러 백엔드가 프로세스 중간에 뱉어 낸 것과 정확히 일치합니다. 이것이 기본적으로 시스템 작동 방식입니다.
원한다면 표준 트리 레이아웃으로 생각할 수 있습니다. 가장자리가 화면 바깥 쪽을 가리키고 (그리고 그 앞에있는 블록에 의해 가려 짐), 중첩은 정점 다이어그램처럼 트리를 표시하는 유효한 방법입니다.
또한 소스에서 노드 그래프로, 그리고 필요할 때 다시 소스로 돌아갑니다. “실제로 하단의”코드보기 “를 클릭하면 이러한 현상이 발생하는 것을 확인할 수 있습니다. 텍스트를 수정하면 다시 구문 분석되고 결과 트리가 렌더링되어 다시 편집 할 수 있습니다. 블록을 수정하면 소스에서도 동일한 일이 발생합니다.
연필 코드는이 시점에서 기본적으로 동일한 작업을 수행합니다. 더 나은 인터페이스 . 사용하는 블록은 CoffeeScript AST의 그래픽보기입니다.따라서 다른 블록 또는 타일 기반 시스템도 대체로 수행합니다. 일부 시스템은 시각적 표현에서 중첩 측면을 상당히 명확하게 나타내지 않으며 많은 경우 실제 텍스트 언어가 없기 때문에 ” 구문 트리 “는 약간 환상적 일 수 있지만 원칙은 있습니다.
그러면 이러한 시스템이 실제로 추상 구문 트리. 사용자가보고 조작하는 것은 공간 효율적인 트리 렌더링이며, 대부분의 경우 컴파일러 또는 파서가 생성하는 AST입니다.
Answer
최소 두 가지 이유 :
-
소스 코드가 훨씬 더 간결하게 표현되기 때문입니다. AST를 그래프로 배치 훨씬 더 많은 시각적 공간을 차지합니다.
프로그래머는 최대한 많은 컨텍스트 (즉, 동시에 화면에 많은 코드가 표시됨)를 갖게됩니다. 컨텍스트를 사용하면 관리를 더 잘 할 수 있습니다. 복잡합니다. (그래서 많은 프로그램이 ammers는 이러한 미친 작은 글꼴과 거대한 30 인치 화면을 사용합니다.)
AST를 그래프 나 트리로 표시하려고하면 단일 화면에 들어갈 수있는 코드의 양이 훨씬 적을 것입니다. 소스 코드로 표현 될 때보 다. 이는 개발자 생산성에 큰 손실입니다.
-
AST “는 프로그래머가 쉽게 이해할 수있는 것이 아니라 컴파일러 프로그래밍을위한 것입니다. 기존 AST 표현을 가져 와서 시각적으로 표시했다면 AST가 개발자가 쉽게 배울 수 있도록 설계되지 않았기 때문에 개발자가 이해하기 어려울 것입니다.
반대로 소스 코드는 일반적으로 은 개발자가 읽고 이해할 수 있도록 설계되었습니다. 이는 일반적으로 AST가 아닌 소스 코드의 중요한 설계 기준입니다. AST는 일상적인 개발자가 아니라 컴파일러 작성자 만 이해하면됩니다. p>
어쨌든 AST 언어는 소스 언어 외에도 개발자가 배워야하는 제 2 언어가 될 것입니다. 승리는 아닙니다.
몇 가지 추가 가능한 이유는 https://softwareengineering.stackexchange.com/q/119463/34181 를 참조하세요.
댓글
- " 반대로 소스 코드는 개발자가 읽고 이해할 수 있도록 설계되었습니다. "-반례 : 대부분의 esolangs, Perl, Lisp
- " Becaus e 소스 코드는 훨씬 더 간결한 표현입니다. "; " AST 언어는 소스 언어 외에 개발자가 배워야하는 두 번째 언어입니다 "-이들은 모든 시각적 PL이지만 OP가 우려하는 구분을 설명하는 데 도움이되지 않습니다.
- " (그 ' 많은 프로그래머가 이러한 미친 작은 글꼴과 거대한 30 " 화면을 사용하는 한 가지 이유입니다.) "-if 충분한 컨텍스트를 보려면 큰 화면이 필요합니다. ' 스파게티 코딩을하고 계십니까? 😉
- @Raphael 아마도,하지만 ' 리팩토링보다 돈을 낭비하는 노력이 적습니다!
- @JanDvorak, .. .LISP는 반례입니다. AST가 언어이기 때문에 표현력이 강합니다. 다른 LISP 코드를 재 컴파일하는 LISP 코드를 작성하는 것은 표준 LISP 데이터 구조를 수정하는 코드를 작성하는 것만 큼 쉽습니다. 정확히 LISP 코드가 작성된 입니다. 반세기 이상 지속 된 ' 이유가 있습니다. ' 가족 ' s 디자인은 드물게 표현력이 있습니다. Go는 비동기 확장을 언어와 런타임에 깊게 연결해야했습니다. Clojure의 경우 '는 단순한 라이브러리입니다. 참조 : 평균 이상 .
답변
컴파일러에 의한 전형적인 AST는 다소 복잡하고 장황합니다. 유 방향 그래프 표현은 빠르게 따라 가기가 매우 어려워집니다. 그러나 AST가 사용되는 CS에는 두 가지 큰 영역이 있습니다.
- Lisp 언어는 실제로 AST로 작성됩니다. 프로그램 소스 코드는 목록으로 작성되며 컴파일러 및 / 또는 인터프리터에서 직접 사용합니다 (사용되는 변형에 따라 다름).
- 모델링 언어, 예 : UML 및 많은 시각적 도메인 특정 언어는 일반적인 범용 언어 AST보다 높은 수준의 추상화에서 추상 구문 그래프 (ASG)에 효과적인 그래픽 표기법을 사용합니다.