rok 언어 참조
이 사양은 rok 프로그래밍 언어의 형식 사양 (formal specification) 입니다. 언어의 문법 (syntax) 과 의미 (semantics) 를 정의하며, 컴파일러와 런타임이 따라야 할 규범적 (normative) 기준을 제공합니다.
기준 시점은 2026-10-23 입니다. 본 사양은 컴파일러와 런타임의 구현이 따라야 할 규범적 기준이며, 컴파일러나 표준 라이브러리의 실제 구현은 별도 저장소에서 다룹니다.
장 목차
rok 의 사양은 0장부터 9장까지 열 개의 장으로 구성됩니다. 각 장은 임의로 나열된 것이 아니라, 한 장의 정의가 그 이전 장의 개념만을 사용해 성립하도록 의존 순서대로 배치되었습니다. 따라서 0장 메타가 가장 앞에 오고, 어휘 구조에서 시작하여 점차 추상도가 높은 영역, 마지막으로 실행 환경과 도구에 다다르도록 흐릅니다.
| # | 장 | 다루는 영역 |
|---|---|---|
| 0 | 메타 - 언어 / 빌드 모델 | 실행 모드, 파이프라인, 표준 라이브러리 계층, 플랫폼, 표기법, 용어집 |
| 1 | 어휘 구조 | 식별자, 키워드, 토큰, 리터럴, 문자열, 구두점 |
| 2 | 타입 시스템 | 원시, 합 / 합성, 제네릭, niche, 변환, 경로 |
| 3 | 표현식 | 연산자, 패턴 매칭, 제어 흐름, 옵셔널 체이닝, throw |
| 4 | 함수 | 매개변수, 클로저, trailing closure, 코루틴, async/await |
| 5 | 변수 / 모듈 / 가시성 / 패키지 | let, const, static, mod, use, 가시성, 경로, 재내보내기 |
| 6 | 메타 시스템 | 속성, lang/literal/keyword 매직, 메타 블록, 리플렉션 |
| 7 | 런타임 모델 | 객체 layout, GC, 스케줄러, 코루틴, 안전점 |
| 8 | 런타임 ABI / MLIR lowering | 헤더, 스캔 테이블, TLS, calling convention, MLIR 다이얼렉트 |
| 9 | 실행 / 툴 | rokc CLI, AOT 파이프라인, .a 패키지, ROKHIR, JIT, Jupyter |
먼저 0장은 이후의 모든 장이 전제하는 빌드 모델, 플랫폼 가정, 표기법을 모아둡니다. 이를 한 번 읽어두면 본문에서 반복되는 약속을 다시 추적할 필요가 없습니다. 그다음 1장 어휘 구조가 가장 앞에 오는 이유는 명료합니다. 토큰의 형태가 정의되어야 비로소 타입과 식이 형식을 갖출 수 있기 때문입니다. 이어지는 2장 타입과 3장 표현식, 4장 함수는 한 모듈 내부에서 값을 만들고 다루는 데 필요한 핵심 구조를 차례로 도입합니다.
5장에 와서야 모듈, 가시성, 패키지가 등장하는 것은 의도된 배치입니다. 단일 파일 안에서 동작하는 의미가 충분히 정의된 뒤에야 파일 경계와 캡슐화를 논할 수 있기 때문입니다. 한편 6장 메타 시스템은 1~5장을 모두 전제로 합니다. 속성, lang / literal / keyword 매직, 리플렉션은 어휘, 타입, 식, 함수, 모듈을 대상으로 동작하므로, 그 대상이 모두 정의된 다음에야 비로소 의미가 분명해집니다.
마지막으로 7장 런타임 모델, 8장 ABI 와 MLIR lowering, 9장 실행과 툴은 표층 언어를 실제 실행으로 옮기는 단계를 다룹니다. 7장이 객체 layout 과 GC, 스케줄러를 추상적으로 기술한다면, 8장은 그것이 메모리와 레지스터에서 어떤 비트로 구현되는지를 못 박고, 9장은 이 모두를 묶어 사용자가 마주하는 rokc CLI 와 빌드 산출물의 형태를 규정합니다.
부록과 참고 자료는 본문에서 자주 참조됩니다.
읽는 방법
처음 읽을 때 (0 → 9 순차)
본 사양은 0장에서 9장까지의 순서대로 읽으면 새로 등장하는 개념이 반드시 직전까지 본 개념만으로 설명되도록 작성되었습니다. 즉, 임의의 장을 펼쳐 보더라도 그 시점까지 이미 읽은 앞 장의 개념만 사용된다는 invariant 가 유지됩니다. 따라서 처음 학습하는 독자라면 순서를 건너뛰지 않고 따라가는 편이 가장 짧은 경로가 됩니다.
cross-reference 의 정의 의존은 backward-only 입니다. 다시 말해, 현재 문서를 이해 하기 위해 그보다 뒤에 오는 문서의 정의가 필요해서는 안 됩니다. 다만 cross-cutting 한 주제 (메서드 디스패치 ↔ 트레잇 dispatch, 산술 식 ↔ 연산자 매직 등) 에서는 보조 참조로 forward 포인터가 등장할 수 있습니다. 그러나 이 경우에도 forward 참조 대상은 현재 문서를 읽는 데 필수 가 아니어야 하며, 어디까지나 추가 맥락을 위한 안내로 한정됩니다.
참조용 (특정 항목 검색)
학습이 아니라 특정 항목을 빠르게 찾기 위한 사용도 자주 일어납니다. 이를 위해 모든 항목에는 안정 섹션 번호 (<chapter>.<section> 또는 <chapter>.<section>.<subsection>) 가 부여되어 있고, cross-reference 는 언제나 이 번호로 합니다. 파일 경로는 시간이 흐르면서 바뀔 수 있으므로 인용에 쓰지 않습니다.
spec 2.7.4 → 002-types/207-niche-optimization.md (4번째 하위 절)
spec 4.8 → 004-functions/408-trailing-closure.md
spec 6.10 → 006-meta-system/610-reflection.md
검색
모든 사양은 마크다운 파일이므로 ripgrep 이나 grep 으로 직접 검색할 수 있습니다. 별도의 인덱스나 검색 도구가 필요하지 않다는 점은 의도된 설계로, 사양을 읽는 일과 사양을 빌드하는 일을 같은 도구만으로 처리할 수 있게 합니다.
rg "trait" spec/ko/refs-lang/
rg "::=" spec/ko/refs-lang/ # BNF 정의 검색
rg "i32" spec/ko/refs-lang/002-types/ # 장 한정
표기 규약
본문 전체에서 일관되게 쓰이는 표기 약속을 아래에 요약합니다. 자세한 정의와 예외는 000-meta/008-notation.md 에서 다룹니다.
| 표기 | 의미 |
|---|---|
`let` | 키워드 / 식별자 (코드 폰트) |
`i32` | 타입 이름 (코드 폰트) |
*emphasis* | 개념 강조 (이탤릭) |
**strong** | 경고 / 핵심 결정사항 (볼드) |
> [!NOTE] / > [!WARNING] | GitHub 스타일 정보 박스 |
name ::= ... | BNF 스타일 문법 정의 |
<chapter>.<section> | 안정 cross-reference 키 (예: 2.7.4) |
코드 폰트는 언어의 표층에 실제로 등장하는 토큰에만 사용하고, 개념적 강조는 이탤릭으로 구분합니다. 또한 핵심 결정사항이나 주의가 필요한 사항은 볼드로 분명히 표시합니다.
디렉토리 / 파일 명명
파일과 디렉토리 이름은 그 자체가 cross-reference 키로 기능하도록 설계되었습니다.
| 위치 | 형태 | 예 |
|---|---|---|
| 장 | <NNN>-<descriptive-name>/ | 002-types/, 006-meta-system/ |
| 섹션 | <NNN>-<name>.md | 207-niche-optimization.md |
| (장 한 자리 + 섹션 두 자리) | ||
| README | 각 장에 README.md | 장 목차 + 안내 |
세 자리 prefix 의 첫 자리는 장 번호, 뒤 두 자리는 섹션 번호입니다. 예를 들어 207 은 "2.7", 즉 타입 시스템 장의 7번째 섹션을 가리키며, 이 숫자가 그대로 cross-reference 의 안정 키로 쓰입니다.
이러한 명명 방식은 Rust Reference 의 descriptive 한 파일명과 hierarchical 한 장 구성, 그리고 Python Language Reference 의 numbered chapter / section 방식을 절충한 결과입니다. 기계가 읽기에는 번호가, 사람이 읽기에는 이름이 더 친절하다는 두 요구를 동시에 만족시키기 위함입니다.