소스 코드 대신 구문 트리를 저장하지 않는 이유는 무엇입니까?

우리는 많은 프로그래밍 언어를 가지고 있습니다. 코드로 변환되기 전에 모든 언어가 구문 분석되고 구문이 검사되어 추상 구문 트리 (AST)가 작성됩니다.

우리는이 추상 구문 트리를 가지고 있는데, 왜 소스 코드 대신 (또는 소스 코드 옆에)이 구문 트리를 저장하지 않습니까?

소스 코드 대신 AST를 사용합니다. 팀의 모든 프로그래머는이 트리를 원하는 적절한 언어로 원하는 언어로 직렬화하고 완료되면 AST로 다시 구문 분석 할 수 있습니다. 따라서 코딩 스타일 질문 ({및}을 넣을 위치, 공백을 넣을 위치, 들여 쓰기 등)에 대한 토론을 제거합니다.

이 접근법의 장단점은 무엇입니까?

공백과 주석

일반적으로 AST에는 공백, 줄 종결 자 및 주석이 포함되지 않습니다.

의미있는 형식

대부분의 경우 이것이 긍정적 인 것 (성전 형식화를 제거함)이며 원본 코드의 서식이 여러 줄 문자열 리터럴 및 "코드 단락"(예 : 빈 줄이있는 문장).

컴파일 할 수없는 코드

많은 파서는 구문 누락에 매우 탄력적이지만, 오류가있는 코드는 종종 매우 이상한 구문 트리를 생성하는데, 이는 사용자가 파일을 다시로드 할 때까지 훌륭하고 멋집니다. IDE에서 실수를 한 다음 갑자기 전체 파일에 "squigglies"가 있습니까? 다른 언어로 어떻게 다시로드 될지 상상해보십시오.

어쩌면 사용자는 구문 분석 할 수없는 코드를 커밋하지 않지만 로컬로 저장해야 할 수도 있습니다.

완벽한 두 언어는 없습니다

다른 사람들이 지적했듯이 완벽한 기능 패리티를 가진 두 개의 언어는 거의 없습니다. 내가 생각할 수있는 가장 가까운 것은 VB 및 C # 또는 JavaScript 및 CoffeeScript이지만 VB에도 C #과 동등한 기능이없는 XML 리터럴과 같은 기능이 있으며 JavaScript에서 CoffeeScript로 변환하면 많은 JavaScript 리터럴이 발생할 수 있습니다.

필자가 작성한 소프트웨어 응용 프로그램에서는 실제로 사용자가 백그라운드에서 JS로 변환되는 "일반 영어"식을 입력해야하므로 실제로이 작업을 수행해야합니다. 우리는 JS 버전 만 저장하는 것을 고려했지만 안정적으로로드 및 언로드되도록 허용 할 수있는 방법이 거의 없었기 때문에 사용자 텍스트와 JS 버전 및 "일반 영어" "버전이 완벽하게 파싱되었습니다.

소스 코드 대신이 구문 트리를 저장하지 않는 이유는 무엇입니까? 팀의 모든 프로그래머는이 트리를 임의의 언어로 직렬화 할 수 있으며 원하는 경우 AST로 구문 분석 할 수 있습니다.

실제로, 그것은 합리적인 아이디어입니다. 마이크로 소프트는 1990 년대에 거의 정확히 그렇게하는 연구 프로젝트를 수행했다 .

몇 가지 시나리오가 떠 오릅니다.

첫 번째는 다소 사소합니다. 말씀 드린대로 간격 등의 다른 프로그래머의 선호도에 따라 AST를 다른보기로 렌더링 할 수 있습니다. 그러나 AST를 저장하는 것은 해당 시나리오에서 과도합니다. 자신에게 예쁜 프린터를 쓰십시오. 파일을 편집기에로드 할 때 pretty-printer를 실행하여 파일을 원하는 형식으로 저장하고 저장할 때 원래 형식으로 되돌립니다.

두 번째는 더 흥미 롭습니다. 추상 구문 트리를 저장할 수 있다면 코드 차이 변경은 텍스트가 아니라 구문이됩니다. 코드가 이동하는 리팩토링은 이해하기가 훨씬 쉬워집니다. 물론 단점은 트리-디프 알고리즘을 작성하는 것이 사소한 것이 아니며 종종 언어별로 수행되어야한다는 것입니다. 텍스트 차이는 거의 모든 언어에 사용할 수 있습니다.

세 번째는 Simonyi가 의도적 프로그래밍을 위해 계획 한 것과 더 비슷합니다. 프로그래밍 언어에 공통적 인 기본 개념은 직렬화되어 있으며, 그 개념에 대해 다른 언어로 렌더링 된 개념이 다릅니다. 아름다운 생각이지만, 추악한 사실은 언어가 세부 사항이 충분히 다르기 때문에 최저 공통 분모 접근법이 실제로 작동하지 않는다는 것입니다.

요컨대, 그것은 멋진 아이디어이지만 비교적 적은 이익을 위해 엄청난 양의 추가 작업입니다. 그렇기 때문에 누구도 거의하지 않습니다.

이것이 .NET의 바이트 코드와 정확히 일치한다고 주장 할 수 있습니다. 실제로 redgate의 리플렉터 프로그램은 바이트 코드를 다양한 .NET 프로그래밍 언어로 다시 변환합니다.

그러나 문제가 있습니다. 구문은 다른 언어로 표현되지 않은 한 언어로 표현할 수있는 것만큼이나 언어마다 다릅니다. 이는 .NET에서 발생하며 C ++은 7 개의 모든 액세스 수준에 액세스 할 수있는 유일한 .NET 언어입니다.

.NET 환경 외부에서는 훨씬 까다로워집니다. 그런 다음 각 언어는 고유 한 관련 라이브러리 세트를 갖기 시작합니다. 매우 다른 방식으로 유사한 문제를 해결하는 것과 동일한 명령 실행을 반영한 C와 Java의 일반 구문을 반영하는 것은 불가능합니다.

나는 당신의 생각과 비슷하지만 언어를 언어로 번역하는 것이 얼마나 쉬운 지 과대 평가하고 있습니다. 그렇게 쉬운 경우에는 언어 X를 AST로 구문 분석 한 다음 AST에서 언어 Y로 이동할 수 있으므로 AST를 저장할 필요조차 없습니다.

그러나 컴파일러 사양이 일종의 API를 통해 일부 AST를 노출하는 것에 대해 조금 더 생각하기를 바랍니다. 애스펙트 지향 프로그래밍, 리팩토링 및 정적 프로그램 분석과 같은 것은 이러한 기능의 구현자가 컴파일러 작성자가 이미 구현 한 많은 작업을 다시 수행하지 않고도 이러한 API를 통해 구현 될 수 있습니다.

프로그램을 표현하기위한 프로그래머의 데이터 구조가 문자열을 포함하는 파일 묶음으로 자주 나타나는 것은 이상합니다.

가장 두드러진 점은 다음과 같습니다.

• 이점이 없습니다. 당신은 모든 사람들이 그들의 애완 동물 언어를 사용할 수 있다는 것을 의미한다고 말했습니다. 그러나 이는 사실이 아닙니다 . 구문 트리 표현을 사용하면 구문상의 차이 만 제거되지만 의미 상 차이는 제거되지 않습니다. VB 및 C # 또는 Java 및 스칼라와 같은 매우 유사한 언어에서 어느 정도 작동합니다. 그러나 완전히 거기조차도 없습니다.

• 문제가 있습니다. 언어의 자유를 얻었지만 도구의 자유를 잃었습니다. 더 이상 텍스트 편집기 나 IDE 에서 코드를 읽고 편집 할 수 없습니다. 코드를 읽고 편집하기 위해 AST 표현을 말하는 특정 도구에 의존 합니다. 여기서 얻은 것이 없습니다.

  이 마지막 요점을 설명하기 위해 강력한 기본 방언의 독점 구현 인 RealBasic을 살펴보십시오. 한동안 언어가 이륙 할 수있는 것처럼 보였지만, 독점적 인 비 텍스트 형식으로 저장 되었기 때문에 IDE에서만 코드를 볼 수 있다는 점까지는 완전히 벤더에 따라 다릅니다. 큰 실수입니다.

텍스트와 AST를 모두 저장하면 텍스트가 이미 한 언어로되어 있으므로 텍스트에서 AST를 빠르게 재구성 할 수 있기 때문에 유용한 것을 실제로 추가하지 않은 것 같습니다.

반면에 AST 만 저장하면 복구 할 수없는 설명과 같은 항목이 손실됩니다.

다른 프로그래밍 언어는 다른 언어와 동등한 것이 아닌 다른 구문을 지원하므로 다른 아이디어는 이론적으로 흥미롭지 만 실용적이지는 않습니다.

예를 들어 X ++에는 많은 추가 코드 (추가 클래스, 추가 논리 등)가 없으면 C #으로 작성할 수없는 'while select'문이 있습니다. http://msdn.microsoft.com/en-us/library/aa558063.aspx

제가 여기서 말하는 것은 많은 언어들이 같은 언어의 큰 코드 블록으로 번역되거나 다른 언어에는 전혀 존재하지 않는 요소들까지 통하는 설탕을 가지고 있다는 것입니다. AST 접근 방식이 작동하지 않는 이유는 다음과 같습니다.

언어 X의 키워드 K는 AST에서 S1, S2, S3 및 S4의 4 개 문장으로 번역됩니다. AST는 이제 언어 Y로 번역되고 프로그래머는 S2를 변경합니다. 이제 X로 다시 변환하면 어떻게됩니까? 코드는 단일 키워드 대신 4 개의 문장으로 번역됩니다 ...

AST 접근법에 대한 마지막 주장은 플랫폼 기능입니다. 기능이 플랫폼에 내장되면 어떻게됩니까? .NET의 Environment.GetEnvironmentVariable과 같습니다. 어떻게 번역합니까?

JetBrains MPS 라는이 아이디어를 기반으로 구축 된 시스템이 있습니다. 에디터는 조금 이상하거나 다르지만 일반적으로 큰 문제는 아닙니다. 다른 편집기, - 가장 큰 문제는 일반 텍스트 기반 도구를 사용할 수 있도록이 더 이상 텍스트 아니라는 것을 잘한다 grep, sed, 병합은 diff 도구 등

실제로는 AST를 저장하고 편집기에서 AST의 "투영"을 특정 언어로 다시 표시하는 "언어 워크 벤치"라고하는 여러 제품이 있습니다. @ sk-logic이 말했듯이 JetBrains의 MPS는 그러한 시스템 중 하나입니다. 다른 하나는 의도적 소프트웨어의 의도적 워크 벤치입니다.

도메인 별 프로젝션을 만들 수 있기 때문에 특히 도메인 별 언어 영역에서 언어 워크 벤치의 가능성이 매우 높아 보입니다. 예를 들어, 의도적 (Intentional)은 텍스트 기반 프로그래밍 언어로 설명 된 회로보다 도메인 전문가가 논의하고 비판하는 것이 훨씬 쉽고 정확한 회로도로 투사되는 전기와 관련된 DSL을 시연합니다.

실제로, DSL 작업 외에도 개발자가 친숙한 일반적인 프로그래밍 언어로 작업하는 것을 선호하기 때문에 언어 워크 벤치가 느리게 진행되었습니다. 일대일 텍스트 편집기 또는 프로그래밍 IDE와 비교할 때 언어 워크 벤치에는 엄청난 오버 헤드가 있으며 그 장점은 분명하지 않습니다. 내가 본 언어 워크 벤치 중 어느 것도 자체 IDE를 쉽게 확장 할 수있는 지점까지 부팅 할 수 없었습니다. 즉, 언어 워크 벤치가 생산성을 높이기 위해 언어 워크 벤치 도구가 개선되지 않은 이유는 무엇입니까? 더 빠르고 빠른 속도로 더 나은가?

당신은 내 마음을 읽고 있습니다.

몇 년 전에 컴파일러 과정을 밟았을 때 AST를 가져 와서 일반적인 접두사 표기법 대신 접두사 표기법으로 직렬화하고 괄호를 사용하여 전체 문장을 구분하면 Lisp를 얻는다는 것을 알았습니다. 저학년 연구에서 Scheme (Lisp의 방언)에 대해 배웠지 만 결코 그것에 대한 감사를 얻지 못했습니다. 나는 그 과정의 결과로 Lisp와 그 방언에 대해 분명히 감사를 얻었습니다.

제안하는 문제 :

1. 그래픽 환경에서 AST를 작성하는 것은 어렵거나 느립니다. 결국, 우리 대부분은 마우스를 움직일 수있는 것보다 빠르게 타이핑 할 수 있습니다. 그러나 새로운 질문은 "태블릿으로 프로그램 코드를 작성하는 방법"입니다. 하드웨어 키보드가있는 키보드 / 노트북에 비해 태블릿에 입력하는 것이 느리고 번거 롭습니다. 팔레트에서 컴포넌트를 대형 캔버스의 캔버스로 끌어다 놓아 AST를 만들 수 있다면 태블릿의 터치 스크린 장치 프로그래밍이 실제가 될 수 있습니다.

2. 이를 지원하는 기존 도구는 거의 없습니다. 우리는 점점 더 복잡한 IDE와 점점 지능적인 편집기를 만드는 데 수십 년의 개발을 마무리했습니다. 텍스트를 다시 포맷하고, 텍스트를 비교하고, 텍스트를 검색 할 수있는 모든 도구가 있습니다. 트리에서 정규 표현식 검색과 동일한 기능을 수행 할 수있는 도구는 어디에 있습니까? 아니면 두 나무가 다른가요? 이 모든 것은 텍스트로 쉽게 수행됩니다. 그러나 단어 만 비교할 수 있습니다. 단어가 다르지만 의미의 의미가 동일하고 diff 도구가 문제를 일으키도록 변수 이름을 변경하십시오. 텍스트 대신 AST에서 작동하도록 개발 된 이러한 도구를 사용하면 시맨틱 의미를 비교할 수 있습니다. 그것은 좋은 일이 될 것입니다.

3. 프로그램 소스 코드를 AST로 바꾸는 것은 상대적으로 잘 이해되는 반면 (컴파일러와 인터프리터, 그렇지 않습니까?) AST를 프로그램 코드로 바꾸는 것은 그리 잘 이해되지 않습니다. 큰 복소수를 얻기 위해 두 개의 소수를 곱하는 것은 비교적 간단하지만 큰 복소수를 다시 소수로 만드는 것은 훨씬 어렵습니다. 그것이 우리가 AST를 분석하고 디 컴파일하는 곳입니다. 언어 간의 차이가 문제가되는 곳입니다. 특정 언어 내에서도 AST를 디 컴파일하는 여러 가지 방법이 있습니다. 예를 들어 객체 컬렉션을 반복하고 어떤 종류의 결과를 얻습니다. 배열을 반복하면서 for 루프를 사용 하시겠습니까? 그것은 작고 빠르지 만 한계가 있습니다. 어떤 종류의 반복자를 사용하십시오. 컬렉션에서 작동합니까? 이 컬렉션은 가변 크기가 가능하여 속도가 (가능한) 비용으로 유연성을 추가합니다. 지도 / 축소? 더 복잡하지만 암시 적으로 병렬화 할 수 있습니다. 그리고 그것은 환경 설정에 따라 Java만을위한 것입니다.

시간이 지남에 따라 개발 노력이 소비 될 것이며 터치 스크린과 AST를 사용하여 개발할 것입니다. 타이핑은 덜 필요합니다. 현재 컴퓨터를 사용하는 방법을 살펴보면 현재의 논리적 진보로서 # 1이 해결 될 것입니다.

우리는 이미 나무와 함께 일하고 있습니다. Lisp는 단순히 일련 화 된 AST입니다. XML (및 확장명으로 HTML)은 직렬화 된 트리 일뿐입니다. 검색을 위해 XPath 및 CSS (각각 XML 및 HTML)의 두 가지 프로토 타입이 있습니다. CSS 스타일 선택기 및 수정자를 만들 수있는 그래픽 도구를 만들면 # 2의 일부가 해결됩니다. 정규 표현식을 지원하기 위해 이러한 선택기를 확장 할 수있을 때 더 가까워 질 것입니다. 두 개의 XML 또는 HTML 문서를 비교할 수있는 좋은 그래픽 차이 도구를 찾고 있습니다. 사람들이 이러한 도구를 개발하면 # 2를 해결할 수 있습니다. 사람들은 이미 그런 일을하고 있습니다. 그들은 아직 거기에 없습니다.

프로그래밍 언어 텍스트로 AST를 디 컴파일 할 수있는 유일한 방법은 목표를 찾는 것입니다. 기존 코드를 수정하는 경우 수정 된 코드를 시작 코드 (최소 텍스트 차이)와 최대한 비슷하게 만드는 알고리즘을 통해 목표를 달성 할 수 있습니다. 처음부터 코드를 작성하는 경우 목표는 가장 작고 가장 타이트한 코드 일 수 있습니다 (예 : for 루프). 또는 가능한 한 효율적으로 병렬 처리되는 코드 일 수 있습니다 (예 :지도 / 축소 또는 CSP 관련 항목). 따라서 동일한 AST는 목표 설정 방법에 따라 동일한 언어로도 코드가 크게 달라질 수 있습니다. 이러한 시스템을 개발하면 # 3을 해결할 수 있습니다. 계산 상 복잡 할 것이므로 클라이언트-서버 배열이 필요합니다.

스타일 서식에 대한 토론을 제거하려는 의도라면 소스 파일을 읽고 편집하고 표시하기 위해 개인 취향에 맞게 서식을 지정하는 편집기 일 것입니다. 그러나 저장할 때는 팀에서 선택한 스타일로 다시 서식을 지정하십시오 사용합니다.

Emacs 와 같은 편집기를 사용하면 매우 쉽습니다 . 전체 파일의 서식 스타일을 변경하는 것은 세 가지 명령 작업입니다.

또한 로딩시 파일을 자동으로 자신의 스타일로 변환하고 저장시 팀 스타일로 변환하는 후크를 작성할 수 있어야합니다.

소스 코드 대신 AST를 읽고 수정하기가 어렵습니다.

그러나 일부 컴파일러 관련 도구에서는 AST를 사용할 수 있습니다. Java 바이트 코드 및 .NET 중간 코드는 AST와 유사하게 작동합니다.

좋은 생각입니다. 그러나 각 언어의 AST는 다른 언어와 다릅니다.

내가 아는 유일한 예외는 VB.NET 및 C #의 경우입니다. 여기서 Microsoft는 "구문이 다른 정확한 언어"라고 주장합니다. 다른 .NET 언어 (IronPython, F # 등)도 AST 수준에서 다릅니다.

JVM 언어와 똑같은 것은 모두 동일한 바이트 코드를 대상으로하지만 언어 구성은 다르므로 언어와 AST가 다릅니다.

CoffeScript 및 Xtend와 같은 'thin layer'언어조차도 기본 언어 (각각 JavaScript 및 Java)의 이론을 많이 공유합니다. 그러나 AST 수준에서 유지되거나 유지되어야하는 더 높은 수준의 개념을 소개합니다.

Xtend를 Java AST에서 재구성 할 수 있다면 기존 Java 코드에서 마술처럼 더 높은 수준의 추상화를 생성하는 Java-to-Xtend '언 컴파일러'로 정의되었을 것이라고 생각하지 않습니까?