Go의 `defer`를 TypeScript 컴파일러에 추가하기: Go로 작성된 컴파일러에 대한 교육용 패치 # Go의 `defer`를 TypeScript 컴파일러에 추가하기 > *Un patch pédagogique dans un compilateur écrit en Go* [ENCADRE titre="원문"] Go의 `defer`를 TypeScript 컴파일러에 추가하기: Go로 작성된 컴파일러에 대한 교육용 패치 [/ENCADRE] [ENCADRE titre="contenu"] Go의 `defer`를 TypeScript 컴파일러에 추가하기: Go로 작성된 컴파일러에 대한 교육용 패치 [/ENCADRE]

개발 & 코딩 yesterday북마크에 추가

Go의 `defer`를 TypeScript 컴파일러에 추가하기: Go로 작성된 컴파일러에 대한 교육용 패치 # Go의 `defer`를 TypeScript 컴파일러에 추가하기 > *Un patch pédagogique dans un compilateur écrit en Go* [ENCADRE titre="원문"] Go의 `defer`를 TypeScript 컴파일러에 추가하기: Go로 작성된 컴파일러에 대한 교육용 패치 [/ENCADRE] [ENCADRE titre="contenu"] Go의 `defer`를 TypeScript 컴파일러에 추가하기: Go로 작성된 컴파일러에 대한 교육용 패치 [/ENCADRE]
삽화 : Momiji Shirogane

Andrew Healey가 `defer` 키워드 - Go 코드의 핵심 - 를 TypeScript 컴파일러에 직접 주입했으며, 이제 Go로 작성되었습니다. parser, checker, emitter를 이해하기 위한 교과서적인 사례입니다.

시작점

마이크로소프트가 TypeScript 컴파일러를 Go로 재작성한다는 발표(약 10배 빠른 속도를 목표로 하는 'TypeScript Native' 프로젝트)를 한 이후, 컴파일러의 소스 코드는 정말 훌륭한 놀이터가 되었습니다. Andrew Healey는 자신의 블로그에 매우 교육적인 글을 게시했는데, 여기서는 자신의 포크 버전에 Go 언어의 핵심 ergonomic 기능 중 하나인 defer 키워드를 TypeScript에 추가했습니다.

JS 스택에서 주로 온 분들을 위해 간단히 설명하자면, Go에서 defer는 둘러싸는 함수가 반환될 때 실행되도록 함수를 예약하는 역할을 합니다. 이는 보일러플레이트 없이 try { … } finally { … }와 동일하며, 정리 호출이 필요한 호출 바로 옆에 작성됩니다.

f, _ := os.Open("file.txt")
defer f.Close() // 함수가 종료될 때 실행됩니다
// … 나머지 코드

이 패턴은 중첩 없이 리소스(파일, 뮤텍스, 연결)를 해제하는 데 널리 사용됩니다.

분석 내용

이 글의 핵심은 "곧 Go의 defer가 TypeScript에 도입될 것이다"가 아닙니다(스포일러: 그렇지 않을 겁니다). 현대 컴파일러가 새로운 키워드를 추가할 때 어떤 단계를 거치는지 단계별로 따라가는 것입니다. Healey는 다음 단계를 거칩니다:

  1. 스캐너(렉서) - defer를 일반 식별자가 아닌 전용 토큰으로 인식합니다.
  2. 파서 - defer가 문법에서 어디에 위치할 수 있는지 결정합니다(문 수준에서는 가능, 표현식 수준에서는 불가능).
  3. 체커(타입 체커) - defer된 대상이 함수 호출인지 확인합니다.
  4. 이미터 - defer를 JavaScript로 변환합니다. 이 경우, 둘러싸는 함수를 try/finally로 감싸고 defer된 콜백을 언윈드 시점에 실행되는 배열에 쌓습니다.

마지막 단계가 가장 흥미로운데, Go의 defer는 런타임에 의해 구현되는 진정한 언어 메커니즘인 반면, JS에는 이와 비교할 만한 것이 없기 때문입니다. 따라서 desugaring(설탕 제거)을 통해 시뮬레이션해야 하며, 이로 인한 성능, 예외, await 등 여러 제약이 따릅니다.

우리에게 왜 흥미로운가

Go로 작성된 TypeScript 컴파일러가 오픈 소스이기 때문에, 이런 연습은 정말 읽어볼 가치가 있습니다. 왜냐하면:

  • 진정한 현대 컴파일러의 아키텍처(대학Toy 프로젝트가 아님)를 이해할 수 있습니다.
  • 대상 언어(JS)가 필요한 기본 기능이 없을 때 번역 선택이 어떻게 제약되는지 확인할 수 있습니다.
  • 이미 익숙한 프로젝트(tsc)에서 AST → 타입 체킹 → 이밋 과정을amiliarize할 수 있습니다.

한편, Healey의 패치는 데모용으로 제안된 것이며, PR로 제출되지 않았습니다. TC39는 JavaScript 표준에 defer를 채택하지 않았고, Microsoft도 TypeScript에 이와 같은 독점 확장을 추진하지 않습니다.

기억할 점: tsc의 Go 재작성의 진정한 이점은 속도뿐만이 아니라, 고급 TypeScript 전문가가 아닌 사람도 읽기 쉬운 컴파일러가 되었다는 것입니다. 이와 같은 교육적 패치는 점점 늘어나며, 이는 정말 훌륭한 학습 기회입니다.

Resources

인공지능이 작성하고 사람의 편집 감독하에 검수한 기사입니다.

편집팀
이 기사가 도움이 되었나요?

7 명이 이 기사를 좋아합니다

좋아요
K
Kaito KuroganeSenior Dev Writer
Senior polyvalent developer, backend Go + frontend TS, open source contributor.
공유:
LIVERadio Geek Kitsune
눌러서 청취, 모두에게 같은 소리
0··
// 편성표
// all stations
// 트랙 공유 →
토픽
탐색
정보