자체 호스팅 컴파일러가 새로운 언어에 대한 통과 의례로 간주되는 이유는 무엇입니까?

사람들이 언어를 존중할 가치가있는 자체 호스팅 컴파일러를 사용하거나 최소한 가지고 있어야한다고 생각하는 곳이 여러 곳에서 들었습니다.

왜 이런지 궁금합니다. 컴파일러는 작성해야 할 매우 중요한 소프트웨어처럼 보이며 모든 언어가 해당 언어를 만드는 데 적합하지는 않다고 생각합니다. 더 나은 결과를 얻을 수있는 작업을하면서 노력하는 것이 더 합리적이지 않습니까?

더 나은 결과를 얻을 수있는 노력을 기울이는 것이 더 합리적이지 않습니까?

무엇처럼?

컴파일러의 좋은 점은 많은 종속성이 없다는 것입니다. 이로 인해 아직 규모가 크거나 다양한 표준 라이브러리가없는 새로운 언어를 사용할 수 있습니다.

더 좋은 점은 다양한 것들이 필요하지만 잘 연구되고 있다는 것입니다. 다양성은 예제가 언어의 다양한 부분을 테스트하도록 도와줍니다. 잘 공부한다는 것은 비교할 다른 컴파일러가 있다는 것을 의미 할뿐 아니라 자신이하는 일을 아는 학문에 더 많은 신뢰를줍니다.

그리고 컴파일러는 엄청난 작업처럼 보이지만, 대단한 계획에서는 매우 작습니다. 언어 구현자가 새로운 언어로 이전에 한 일조차 할 수 없다면 어떻게 새로운 일을 할 것입니까? 표준 라이브러리 나 IDE와 같은 정말 큰 것들을 어떻게 처리 할 것인가?

컴파일되고있는 언어로 컴파일러를 만드는 목표는 종종 " 자신의 개밥을 먹는 "실천의 일부입니다 . 이는 모듈과 도구를 지원하는 언어, 컴파일러 및 에코 시스템이 "심각한 작업에 적합"하거나 "생산 준비"된 것으로 간주한다는 사실을 세계에 입증합니다.

또한 언어, 컴파일러 및 런타임 디자인에 가장 가까운 사람들이 자신이 내리는 모든 결정의 영향과 선택한 개발 우선 순위 (사마귀 및 모두)의 영향을 직접적으로 받도록 강요하는 효과가 있습니다. 이것은 종종 이론의 언어 환경을 이해하는 것뿐만 아니라 어려운 실제 조건의 도가니에서 언어 / 도구를 사용하여 광범위한 실제 경험을 가진 핵심 그룹으로 이어집니다.

사람들은 한 가지 주된 이유로 새로운 범용 언어를 만듭니다. 그들은 다른 모든 언어에 대해 적어도 한 가지를 싫어합니다. 그렇기 때문에 많은 언어가 사용되지 않는 이유입니다. 프로그래밍 수명을 향상시킬 수있는 언어에 대한 좋은 아이디어가 있지만 적어도 한 가지 방법으로 귀찮은 언어로 첫 구현을해야합니다. 자체 호스팅은 더 이상 오래된 성가신 언어로 작업 할 필요가 없음을 의미합니다. 그렇기 때문에 언어 제작자들이 그 단계를 향해 노력하고 주요 이정표로 간주합니다.

많은 언어 기능이 종이에 잘 어울리지 만 실제 프로젝트에서 사용할 때 한계를 느끼기 시작합니다. 예를 들어, 많은 언어는 처음에는 괜찮은 유니 코드를 지원하지 않습니다. 대규모 프로젝트를 완료하면 이러한 상황을 많이 처리하고 처리 할 수 ​​있으며 자체 호스팅 컴파일러는 그 어느 때보 다 좋은 프로젝트입니다. 그렇기 때문에 언어 제작자 이외의 사람들이이 언어를 주요 이정표로보고 있습니다.

그렇다고 주목할 가치가 있는 유일한 이정표 는 아닙니다 . 데이터베이스 통합, 그래픽 인터페이스, 네트워킹 등과 같은 컴파일러가 사용하지 않는 기능이 있습니다.

Steve Yegge 는 다소 간접적으로 이것을 다루는 훌륭한 블로그 게시물 을 작성했습니다 .

큰 포인트 # 1 : 컴파일러는 컴퓨터 과학의 거의 모든 측면을 포함합니다. 컴퓨터 과학 커리큘럼에서 배우기 시작한 다른 모든 것들을 알아야하기 때문에 상위 과정입니다. 데이터 구조, 검색 및 정렬, 점근 적 성능, 그래프 색상? 모두 거기에 있습니다.

Knuth가 컴파일러 교과서로 시작했지만 수십 년 동안 기념비적이며 끝이없는 "컴퓨터 프로그래밍 기술"을 연구 해 온 이유가 있습니다. Carl Sagan이 말한 것과 마찬가지로 "애플 파이를 처음부터 만들려면 먼저 우주를 발명해야합니다"라고 말하고 컴파일러를 작성하려면 먼저 컴퓨터 과학의 거의 모든 측면을 다루어야합니다.

즉, 컴파일러가 자체 호스팅되는 경우 수행중인 작업에 관계없이 필요한 작업을 수행 할 수 있습니다. 반대로, 언어로 컴파일러를 작성 하지 않은 경우 언어 구현자가 이러한 모든 문제에 대해 생각할 필요가있는 프로그램을 작성할 필요가 없기 때문에 누군가에게 실제로 중요한 것을 놓칠 가능성이 높습니다.

큰 포인트 # 2 : 30,000 피트에서 놀라운 수의 문제가 컴파일러처럼 보입니다.

컴파일러는 심볼 스트림을 가져 와서 도메인 고유의 미리 정의 된 규칙에 따라 구조를 파악하여 다른 심볼 스트림으로 변환합니다. 꽤 일반적으로 들리지 않습니까? 그래

Visual C ++ 팀에 있든 없든 컴파일러의 일부처럼 보이는 작업을 수행해야하는 경우가 종종 있습니다. 나는 문자 그대로 매일 그것을한다.

대부분의 다른 직업과 달리 프로그래머는 도구를 사용하는 것이 아니라 자체 도구를 작성합니다. 기술이 부족하거나 다른 도구를 만드는 데 사용할 수있는 도구가 없기 때문에 도구를 작성할 수없는 프로그래머는 다른 사람이 제공하는 도구로 제한 될 수 있습니다.

언어가 기호 스트림을 가져 와서 규칙을 적용하고 다른 기호 스트림으로 변환 할 수있는 프로그램을 "제작하기에 적합하지 않은"경우, 이는 매우 제한적인 언어처럼 들리지만 유용하지는 않습니다. 나에게.

(다행히도 기호를 변환하는 데 적합하지 않은 프로그래밍 언어가 많지 않다고 생각합니다. C는 오늘날 사용되는 최악의 언어 중 하나이지만 C 컴파일러는 일반적으로 자체 호스팅되므로 아무도 중단하지 않습니다.)

Yegge가 언급하지 않은 개인적인 경험으로 끝나는 세 번째 이유 는 ( "자기 호스트 이유"에 대해 글을 쓰지 않았기 때문에) 버그를 흔든다는 것입니다. 컴파일러를 작성할 때 즉, 컴파일러 를 실행할 때마다 빌드 할 때마다 (컴파일러 자체) 제대로 작동하고 적절한 크기의 코드베이스 (컴파일러 자체)에 대해 올바르게 작동해야합니다.

이번 달에는 비교적 새롭고 자체 호스팅되지 않은 컴파일러를 사용하고 있었으며 (어쩌면 어느 것을 추측 할 수 있습니까?)이 문제를 해결하지 않고 2 일 동안 갈 수는 없습니다. 디자이너들이 실제로 얼마나 사용해야하는지 궁금합니다.

언어 X에 대한 컴파일러를 자체 호스팅으로 사용하려면 먼저 언어 X에 대한 입력을 받아 어셈블리 코드 또는 일부 중간 코드를 뱉거나 심지어 Y와 같은 다른 언어로 구현해야합니다. 컴파일러가 실행중인 머신의 오브젝트 코드 어떤 시점에서 Y로 작성된 코드를 X로 변환하기 때문에 언어 Y를 가능한 언어 X와 유사하게 선택하려고합니다.

그러나 필요한 것보다 더 많은 언어 Y로 컴파일러를 작성하고 싶지 않기 때문에 우선 언어의 일부만 구현하여 중복 구문을 제거합니다. 는 'C'형 언어의 경우, 잠시 하지만 위한 또는 동시에 수행 . 만약 어떤하지만 경우 또는 차 연산. 구조 나 공용체 또는 열거 형이 없습니다. 당신이 남긴 것은 언어 X에 대한 파서와 기초 코드 생성기를 작성하기에 충분한 언어입니다. 그런 다음 출력을 확인하십시오. 다시.

이 작업을 마치면 언어 Y로 작성된 컴파일러 소스를 언어 X로 다시 작성하고 언어 Y로 작성된 컴파일러를 사용하여 언어 X 소스를 컴파일 할 수 있습니다. 출력은 새 언어 X로 작성된 새 컴파일러가됩니다. 언어 X를 컴파일합니다. 즉, 이제 자체 호스팅입니다. 그러나 언어 Y의 언어 서브 세트 만 구현했기 때문에 완료되지 않았습니다.

이제 누락 된 기능을 추가하여 각 기능 (또는 기능 그룹)이 올바른 코드를 생성하는지 테스트합니다. 즉, 일단 기능이 컴파일러에서 구현되면 새로운 기능을 사용하여 테스트 프로그램을 작성하고 컴파일 및 테스트 할 수 있지만 아직 컴파일러 소스에서 사용해서는 안됩니다. 새로운 기능이 확인되면 컴파일러 소스 자체에서 이러한 새로운 기능을 사용할 수 있습니다 (언어 하위 세트로 작성된 일부 원래 코드를 대체 할 수도 있음). 새 기능이있는 버전을 사용하여 컴파일러 소스를 다시 컴파일하십시오.

이제 언어에 새로운 기능을 추가 할 수있는 메커니즘이 생겼으며, 기능에 대한 코드 생성이 올바르게 확인되면 차세대 컴파일러 자체에서 사용할 수 있습니다.

60 년 전, 컴퓨터가 현장에 처음 도착했을 때 (그리고 나중에 마이크로 프로세서가 처음 도착했을 때), 초기 컴파일러를 구현하기에 적합한 다른 언어는 없었습니다. 따라서 첫 번째 컴파일러는 어셈블리 코드로 작성되어야하고, 컴파일러가 충분히 실행될 때 어셈블리 코드는 새 언어로 작성된 버전으로 대체됩니다. 어셈블러도 없습니까? 전체 프로세서는 어셈블러가 기계 코드로 처음 작성된 다른 수준으로 떨어졌습니다 .

컴파일러 작성을 위해 잘 설계되지 않았지만 다른 목적으로 잘 설계된 프로그래밍 언어를 생성 할 수 있습니까?

SQL과 같은 언어를 보면 대답이 예라고 생각합니다. 그러나 그 자연의 언어는 일반적인 목적이 아닙니다.

누가 그렇게 말합니까? 어쨌든, 그것은 단지 의견 일뿐입니다. 어떤 사람들은 여기에 옳고 그름이 없다고 동의 할 수도 있고 그렇지 않을 수도 있습니다. 일부 언어에는 자체 컴파일러가 있지만 다른 언어에는 컴파일러가 없습니다. 도대체 무엇이.

그럼에도 불구하고 언어가 "자체 컴파일"할 수 있다면 그것은 훌륭한 연습 / 개념 증명이라고 생각합니다.

또한 훌륭하지만 컴파일러가 다른 언어로 작성된 여러 가지 이유가 여전히 있다고 언급하고 싶습니다. 예를 들어, 대부분의 자바 스크립트 엔진은 자바 스크립트로 작성되지 않습니다. 다른 소프트웨어와의 통합, 기존 라이브러리 / 종속성에 대한 링크, 우수한 도구, 성능, 레거시 코드 등 여러 가지 이유가 있습니다. 언어 자체 컴파일이 좋지만 핵심 컴파일러를 유지하는 것이 합리적입니다. 다른. 그러나 언어 자체가 의미가 있습니다. 일반적으로 전체 생태계를 재개발 할 여유가 없습니다.

Clang은 C ++로 작성되었습니다. Objective-C에서 Clang Objective-C 컴파일러를 다시 작성하는 것은 어렵지 않지만 매우 쓸모가 없습니다. C ++ 컴파일러의 모든 변경 사항은 Objective-C에서 다시 수행해야하고 그 반대도 마찬가지입니다. 왜?

Clang Swift 컴파일러가 있습니다. 분명히 컴파일러는 Swift에서 다시 작성할 수 있습니다. 그러나 어떤 목적이 될까요? 언어가 컴파일러를 작성할 수있을만큼 강력하다는 것을 보여주기 위해? Swift에서 컴파일러를 작성할 수 있는지 아무도 신경 쓰지 않습니다. 사람들 은 Swift에서 사용자 인터페이스를 작성할 수 있는지주의를 기울이고 설명 할 수 있습니다.

다른 언어를 컴파일하도록 쉽게 조정할 수있는 잘 테스트 된 컴파일러가있는 경우, 다른 언어로 다시 쓰면 컴파일러에서 더 쉽게 작업 할 수 없다면 다른 언어로 다시 쓰면 무의미합니다. 예를 들어 Clang을 Swift로 작성하는 것이 합리적이라면 Clang C, C ++ 및 Objective-C 컴파일러는 모두 Swift로 작성됩니다.

일부 프로그래밍 언어로 컴파일러를 작성할 수 있다는 것을 증명하는 것보다 더 중요한 일이 있습니다.

언어가 복잡한 문자열 처리를 처리하고 다른 언어로 번역 / 번역 할 수 있음을 보여줍니다.

컴파일러 (첫 번째 큰 프로젝트)를 만드는 과정에서 문제가 발생할 것입니다.