Files
coollang/dogfoods/README.md
T
coolguyandClaude Opus 5 450e96d326 dogfoods: LRU 캐시 — 비렉시컬 정리, 그리고 Option/Result 패턴의 큰 버그
파일과 풀은 정리 지점이 렉시컬이었다. LRU는 아니다 — 축출은 삽입의 부작용으로
예측할 수 없는 때에 일어난다. with를 구현하기 전에 알아야 할 자리였다.

D10 (큰 것) — Option/Result 패턴이 타입을 통째로 잃고 있었다.
  match r { Ok(v) => v, Err(e) => e }   // Int를 String 자리에 두는데 통과
typecheck의 env.ctors에 내장 생성자가 없어서 None이 "None이라는 이름의 변수
바인딩"이 되고 Ok(v)의 v가 TUnknown이 됐다. 즉 이 언어의 핵심 오류 처리
수단의 패턴 매칭이 타입을 전혀 검사하지 않고 있었다. 소진성 검사는 자기
is_ctor에 내장을 갖고 있어 이 사실을 덮었다 — 빠진 경우는 잡으면서 타입은
안 봤다. 내장 열거형을 등록해 고쳤고 기존 코드는 하나도 안 깨졌다.
여태 안 보인 이유: Ok(v) => Int.show(v) 같은 정상 코드는 v가 TUnknown이어도
통과하므로 아무도 이상함을 못 느낀다. 틀린 코드를 써봐야 드러난다.

D11 — struct 필드에서 affine 값을 꺼낼 수 없다. 필드 접근은 빌림이고 struct
분해 패턴이 없다. 열거형은 패턴이 분해하므로 가능하다. 즉 "둘을 함께
돌려주기"가 열거형으로만 된다. 튜플이 없는 대가가 표현 가능성 문제로 나왔다.

D12 — 축출은 렉시컬이 아니다. 그래서 자원이 렉시컬 전용이면 자원 컨테이너를
언어로 만들 수 없다. 이미 그렇게 되어 있었다 — std-draft의 Pool이 불투명한
런타임 capability인 이유가 만들 수 없어서였다. (a) 렉시컬 전용을 택하고,
사용자가 자기 자원 풀을 못 만든다는 대가를 기록한다.

자료구조 자체의 마찰: Map이 없어 O(n), 튜플이 없어 운반용 struct 세 개,
get이 캐시를 새로 돌려줘야 함, 뒤에서 자르는 std 함수 없음.

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

2.8 KiB

dogfoods — 실제 유스케이스로 언어를 압박한다

samples/가 검사기를 시험한다면 여기는 언어가 실제 문제를 표현할 수 있는지를 시험한다. 성격이 다르므로 폴더를 나눈다.

방법

프로그램을 쓰되 돌리지 않는다. std-draft/에 런타임이 구현한다고 가정한 선언을 두고, 그것에 대고 실제 프로그램을 쓴다.

"가상"이 아니다. std/*.cool이 원래 본문 없는 선언이므로 실행만 빼고 전부 진짜로 검사된다:

lexer ✓  parser ✓  이름 해소 ✓  타입 ✓  effect ✓
capability ✓  move/affinity ✓  소진성 ✓  interface hash ✓
run ✗

종이 스케치가 아니라 컴파일러가 검증한 설계다.

합격 기준

① coolc check       exit 0
② 모듈이 실제로 해소될 것

②가 없으면 ①이 공허하다. import가 조용히 해소되지 않으면 그 모듈의 이름이 전부 불투명해지고, 검사기는 "모르는 것을 틀렸다고 말하지 않는다"는 원칙에 따라 무엇이든 통과시킨다. 실제로 첫 시도에서 이 일이 일어났다 (D1 참고).

규율

std-draft의 선언은 독립적으로 정당화되어야 한다.

  • 지금 런타임이 가진 권한으로 구현 가능할 것
  • effect를 전부 선언할 것
  • 실패 양상을 선언하는 자리에서 정할 것 — 무엇이 Result이고 무엇이 crash인지
  • 없는 언어 기능에 기대지 말 것. 필요하다는 것이 드러나면 그것이 발견이지 지름길이 아니다

프로그램이 예뻐 보이도록 API를 발명하면 아무것도 배우지 못한다.

한계

이 기준이 증명하는 것은 표현 가능성이지 의미론의 정확성이 아니다. check가 통과한다고 그 프로그램이 옳게 도는 것은 아니다 — 돌려본 적이 없다.

세트

압박하는 곳 상태
1 Mini Shell 소유권 / OS 핸들 대기
2 Atomic File Updater 자원 수명, 실패 경로 완료
3 Process Supervisor 실패 위상 대기
4 Reverse Proxy 취소, backpressure 대기
5 TCP Server 규모의 API 모양 대기
6 DB Pool lease, 자원 정리 완료
+ LRU Cache 비렉시컬 정리 (축출) 완료
7 Resource Exhaustion 실패 의미론의 최악 조건 미룸 — 런타임 속성이라 안 돌리면 알 수 없다. 언어 층 질문("무엇이 Result이고 무엇이 crash인가")은 std-draft 규율로 흡수했다

순서는 자원 모델(2, 6, 1) → 동시성·취소(3, 4, 5)다. 2번을 먼저 둔 이유는 동시성을 안 섞고 자원 모델만 시험할 수 있는 유일한 것이기 때문이다.

발견은 FINDINGS.md에 쌓고, 확정된 결정은 docs/thesis.md로 올린다.