coolguyandClaude Opus 5 78ef07d2ee panic: panic/Never와 내장 테스트 — 문법을 먼저 고치고 대조 장치가 파서를 지적했다
순서가 요점이다. 문법에 test_decl과 panic_expr을 넣고 파서는 안 고친 채로
대조 장치를 돌렸더니 즉시 잡혔다:

  문장 300개 중 파서가 거부한 것 140개
  [1] 선언 (fn, struct, enum, capability, const)이(가) 필요합니다 — test 발견

파서를 따라가게 하니 다시 0건. 문법과 구현이 어긋나는 상태가 관측 가능한
것이 되었다는 뜻이다.

panic:
- 키워드다. prelude가 없어 함수로 두면 쓸 때마다 import해야 한다
- effect가 아니다. 경계 검사 하나에 {Panic}이 호출자 전부로 전염되면
  effect 절은 신호가 아니라 잡음이 된다
- Never는 어떤 타입 자리에도 놓인다. 없으면 panic을 match 팔에서 못 쓴다
- 언어 수준 recover 없음. 되감기 없음. 자원 해제 여부는 열어둔다
- 0으로 나누기, assert 실패가 이 하나로 모인다

test:
- 파라미터가 없어 capability를 받을 수 없고, 만들 문법도 없다. 그래서
  effect-free임이 증명된다 — 관례가 아니라 검사다. 시험해 보니 실제로
  "테스트는 effect를 수행할 수 없습니다"로 거부한다
- 일반 코드와 같은 타입/effect/move 검사를 받는다
- interface hash에서 제외 — 테스트를 고쳤다고 downstream이 재검사되면 안 된다
- 격리는 런타임의 일이다. 하나가 죽어도 나머지는 돈다

assert는 std/test.cool에 coollang으로 쓰였다 — panic 위의 설탕임이 코드로
보이고, std에서 본문이 있는 첫 함수가 됐다. 그 바람에 std/런타임 양방향
테스트가 걸렸고(본문 있는 함수에 런타임 구현을 요구했다), 그 구분을 넣었다.

samples/app/config.cool에 첫 테스트 넷.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019ZVDeU6KLuUVL3gs18Hm3E
2026-08-30 17:51:56 +09:00

coollang

되돌리기 비싼 결정부터 확정하는 프로그래밍 언어. 현재 v0 — 설계 검증판.

$ coolc check samples/run/hello.cool
$ coolc run   samples/run/hello.cool
area = 12
area = 9
area = 3

무엇을 위한 언어인가

세 가지 목표가 나머지 모든 결정을 지배한다.

  1. 오류를 더 빨리 잡는다 — null 없음, Option/Result, 소진적 match, 확정 초기화, 선언되지 않은 effect는 컴파일 오류.
  2. 검증이 더 빠르다 — fast path / slow path 분리, 전역 추론 없음, 복잡한 trait solver 없음, 임의 매크로 없음, 인터페이스 해시 기반 무효화.
  3. 피해 범위가 좁다 — 명시적 capability, ambient authority 없음, affine 소유권.

설계의 전문은 docs/thesis.md, 문법은 docs/grammar.ebnf에 있다.

지금 되는 것

lex → parse → 이름 해소 → 타입 검사 → effect/capability 검사 → move/affinity 검사 → 소진성 검사 → interface 해시 → typed IR → 인터프리터

여섯 종류의 오류를 한국어 진단으로 보고한다: 문법, 이름, 타입, effect, capability, 소유권. 여기에 match 소진성과 두 가지 lint(미사용 import, effect 과잉 선언)가 더해진다.

$ coolc check samples/12_stdlib_effects.cool
samples/12_stdlib_effects.cool:20:14: 선언되지 않은 effect Console.print
  (leaks_effect의 effects 절은 {}입니다)

증분 검사

이 프로젝트의 중심 주장이다. 10만 줄 / 200 모듈에서 측정 (bench/bench.ml):

시간 재검사한 모듈
전체 검사 (cold) 253ms 200
함수 본문만 수정 0.8ms 1
함수 시그니처 수정 2.5ms 2

핵심은 시간이 아니라 범위다. 본문 수정이 downstream을 한 칸도 건드리지 않는 것, 그리고 시그니처 수정이 사슬 끝까지 가지 않고 해시가 변한 곳에서 멈추는 것 — 이 둘이 아키텍처의 주장 전부다.

시그니처 수정 시나리오에서는 두 모듈 건너의 match가 실제로 깨진다:

m100.cool:15:3: match가 모든 경우를 덮지 않습니다 (빠진 경우: Tri(_))
m101.cool:21:3: match가 모든 경우를 덮지 않습니다 (빠진 경우: Up.Tri(_))

실제로 써본 결과

samples/app은 검사기를 시험하려고 쓴 것이 아니라 일을 하려고 쓴 프로그램이다 — 설정 파서 + 리포트 도구, 2모듈 232줄.

$ coolc run samples/app/main.cool samples/app/example.conf
설정
  name = "coollang"   (text)
  threads = 4   (number)
  ...
항목 5개, 문제 2개

문제
  10행: 이름이 비어 있습니다
  11행: = 가 하나여야 합니다: broken = a = b

쓰면서 걸린 것들을 docs/friction.md에 남겼다. 요약하면: 되돌리기 비싼 결정은 하나도 후회되지 않았고, 불편은 전부 되돌리기 싼 것들이었다.

빌드

OCaml 5.x와 dune이 필요하다.

opam install dune
dune build
dune test          # 175개 검사
dune exec bench/bench.exe

coolc_build/default/bin/main.exe다. 설치하려면 dune install.

저장소 구성

lib/          컴파일러 (약 4,900줄 OCaml)
  lexer.ml      어휘 분석 — 문법을 하나도 모른다
  parser.ml     재귀 하강, LL(1), backtracking 없음
  resolve.ml    이름 해소 — 모듈 하나만 보고 결정할 수 있는 것
  typecheck.ml  타입 + effect + capability
  move.ml       move / affinity
  exhaust.ml    소진성 (Maranget usefulness)
  iface.ml      interface artifact + 해시
  session.ml    모듈 로딩 + 고정점 invalidation
  ir.ml         얇은 typed IR
  interp.ml     트리 워킹 인터프리터
std/          표준 라이브러리 (본문 없는 선언, 런타임이 구현)
samples/      예제 — 통과용 9개, 일부러 틀린 것 7개
bench/        증분 루프 측정

v0의 성격

이것은 쓸 수 있는 언어가 아니라 설계가 옳은지 증명된 언어다. 되돌리기 비싼 결정 — 문법, 타입, effect, capability, 소유권, 증분 아키텍처 — 이 전부 코드와 테스트로 못 박혔고, 빠른 검증 루프라는 시스템 속성이 측정으로 증명됐다.

그래서 이 코드를 통째로 버리고 v1로 번역해도 잃을 것이 없다. 애초에 그것이 v0의 목적이었다.

아직 없는 것: 진짜 컴파일(해석 실행만 한다), 병렬 실행(scope는 순차), 파일·네트워크 IO, 완전한 제네릭, 에디터 지원, 패키지 관리자. 표준 라이브러리는 len, each, map, concat, show 수준이다.

이름

언어는 coollang, 툴체인 바이너리는 coolc. 소스 확장자는 .cool.

S
Description
되돌리기 비싼 결정부터 확정하는 프로그래밍 언어. v0 — 설계 검증판.
Readme
739 KiB
Languages
OCaml 99.9%