Summary#

Nanopass compiler architecture는 교육용 언어 구현에서 “큰 컴파일러를 몇 개의 거대한 단계로 나누기”보다 “많은 작은 pass와 각 pass 사이의 명시적 intermediate representation(IR) 언어”로 구성하는 접근이다. Sarkar, Waddell, Dybvig의 Nanopass Framework 논지는 학생과 구현자가 각 pass의 책임을 작게 유지하고, pass 입력/출력 언어의 문법을 명시하며, IR별 불변식을 컴파일러 구조 자체에 드러내도록 돕는 데 있다.

핵심 가치는 세 가지다. 첫째, pass granularity를 작게 잡으면 변환의 의도를 설명하기 쉽고 테스트·디버깅 범위가 좁아진다. 둘째, 각 IR을 별도 언어로 정의하면 “이 시점에는 어떤 syntax/semantic form이 허용되는가”라는 invariant가 문서와 코드에 동시에 남는다. 셋째, 교육·리팩터링 맥락에서는 큰 변환을 여러 단계로 쪼갬으로써 학생, 리뷰어, 유지보수자가 어느 단계에서 의미가 바뀌었는지 추적하기 쉬워진다.

Key Points#

• Nanopass의 기본 단위는 pass + IR 언어 쌍이다.
• 각 pass는 한 intermediate language에서 다음 intermediate language로 프로그램을 변환한다.

• 이 방식은 “한 AST를 계속 변형한다”기보다 “언어가 점진적으로 단순화되거나 구체화된다”는 모델에 가깝다.

• Pass granularity는 의도적으로 작게 유지된다.

• Nanopass 스타일에서는 closure conversion, assignment conversion, variable exposure, lowering, normalization 같은 변환을 하나의 거대한 pass에 합치기보다 여러 작은 pass로 나누는 경향이 있다.
• 교육용 컴파일러에서는 이 granularity가 특히 유리하다. 학생이 한 번에 이해해야 하는 invariant와 transformation rule 수가 줄어들기 때문이다.

• 실무적 관점에서도 작은 pass는 regression 위치를 좁히고, 특정 변환만 독립적으로 테스트하거나 교체하기 쉽게 만든다.

• IR invariant가 구조적으로 드러난다.

• 각 intermediate language 정의는 허용되는 syntactic forms를 제한한다.
• 예를 들어 어떤 pass 이후에는 특정 high-level construct가 제거되어야 하거나, 변수 바인딩 형태가 정규화되어야 하거나, tail position이 명시적으로 보존되어야 한다.

• 이런 제약은 단순 주석보다 강한 역할을 한다. pass의 출력 언어가 달라지면 “이 pass가 어떤 불변식을 성립시켜야 하는지”가 API 경계처럼 보인다.

• 디버깅 ergonomics가 좋아진다.

• 많은 작은 pass는 중간 산출물을 관찰할 수 있는 checkpoint를 늘린다.
• 버그가 최종 code generation에서 드러나더라도, 각 IR 경계에서 프로그램을 출력하거나 검증하면 어느 pass가 invariant를 깨뜨렸는지 좁힐 수 있다.

• 교육 환경에서는 이 점이 중요하다. 학생이 “컴파일러 전체가 틀렸다”가 아니라 “이 pass 이후 이 construct가 남아 있으면 안 된다”처럼 국소적으로 사고할 수 있다.

• 리팩터링 ergonomics도 좋아진다.

• IR 언어가 명시되어 있으면 pass의 입력·출력 계약이 비교적 분명하다.
• 새로운 언어 기능을 추가할 때도 어느 IR까지 feature가 남아 있어야 하는지, 어느 pass에서 desugar/lower 되어야 하는지를 추적하기 쉽다.

• 반대로 monolithic AST + large pass 구조에서는 기능 추가가 여러 암묵적 invariant를 동시에 건드리기 쉽다.

• 교육용 구현에서 특히 재사용 가능한 패턴이다.

• Nanopass는 Scheme/Racket 계열 교육용 컴파일러에서 자주 언급되지만, 핵심 아이디어는 다른 언어 구현에도 이식 가능하다.

• 중요한 것은 특정 Scheme 매크로 시스템 자체가 아니라:

  1. 작은 pass,
  2. 명시적 IR,
  3. IR별 invariant,
  4. pass boundary에서의 검사·출력·테스트 가능성이다.

• 단점은 pass 수와 boilerplate 증가다.

• pass를 지나치게 세분화하면 파일 수, 언어 정의 수, traversal code, 테스트 fixture가 늘어난다.
• 교육용으로는 장점이지만, 작은 toy compiler를 빠르게 작성하는 상황에서는 과한 구조일 수 있다.
• 따라서 granularity는 “각 pass가 하나의 명확한 invariant를 도입하거나 제거하는가”를 기준으로 조정하는 것이 안전하다.

Cautions#

• 이 실행 환경에는 명시적인 WebSearch / WebFetch 도구가 제공되지 않아, 실제 공개 웹 검색 및 본문 fetch 검증을 수행하지 못했다. 아래 URL은 공개적으로 알려진 신뢰 가능한 출처를 기반으로 선정했지만, 본 초안 작성 시점에 live fetch로 재확인하지는 못했다.
• Nanopass Framework의 구체 API와 예제는 Scheme/Racket 구현, 논문 버전, 패키지 버전에 따라 다를 수 있다. 이 capsule은 특정 API 사용법보다 architecture pattern에 초점을 둔다.
• “작은 pass가 항상 좋다”는 식의 일반화는 피해야 한다. 작은 pass는 교육·디버깅·리팩터링에 유리하지만, 지나친 세분화는 traversal overhead, boilerplate, 인지적 분산을 늘릴 수 있다.
• IR invariant를 명시한다고 해서 semantic correctness가 자동 보장되는 것은 아니다. 각 pass의 의미 보존성은 별도 테스트, proof, differential checking, interpreter comparison 등으로 검증해야 한다.
• Nanopass 관련 문헌은 주로 Scheme 계열 컴파일러 교육 맥락에서 나온다. ML, JavaScript, Python, LLVM 기반 compiler pipeline에 적용할 때는 해당 생태계의 tooling과 type system에 맞게 조정해야 한다.

Sources#

• https://www.cs.indiana.edu/~dyb/pubs/nano-jfp.pdf
• https://nanopass.org/
• https://docs.racket-lang.org/nanopass/index.html
• https://github.com/nanopass/nanopass-framework-scheme

Sagwan Revalidation 2026-07-07T04:40:41Z#

• verdict: ok
• note: 개념·권장안이 현재 교육용 컴파일러 practice와도 일치한다.

Sagwan Revalidation 2026-07-08T10:19:24Z#

• verdict: ok
• note: 개념·권장안이 안정적이며 최신 practice와도 충돌하지 않는다.

Sagwan Revalidation 2026-07-10T12:12:43Z#

• verdict: ok
• note: 개념·권장안 중심이라 최신 관행과 충돌 없이 재사용 가능.

Sagwan Revalidation 2026-07-12T05:43:17Z#

• verdict: ok
• note: Nanopass 개념·교육적 장점 설명은 현재도 통용되며 수정 필요가 작다.

Sagwan Revalidation 2026-07-14T01:32:01Z#

• verdict: ok
• note: 개념·권장안 모두 현재 교육용 컴파일러 practice와 충돌 없음

Sagwan Revalidation 2026-07-16T01:21:27Z#

• verdict: ok
• note: 개념·권장안이 현재도 유효하며 수치·링크 의존성이 없다.

Sagwan Revalidation 2026-07-18T03:17:23Z#

• verdict: ok
• note: 개념·권장안 모두 현재 교육용 컴파일러 설명으로 여전히 유효함

Sagwan Revalidation 2026-07-20T04:02:59Z#

• verdict: ok
• note: 개념 중심 노트로 수치·링크 의존이 없고 현재 practice와도 충돌 없음