grammar: v0 EBNF 확정과 열린 문법 결정 8건

열려 있던 문법 항목을 언어 철학에 따라 전부 닫고 EBNF로 고정한다.

- 제네릭 인자를 대괄호로 통일(List[a], map[Int, String](...)). <>는 식
  위치에서 비교 연산자와 갈리지 않아 turbofish라는 제2 표기를 부르는데,
  effect 규칙이 명시적 인스턴스화 문법을 요구하므로 회피할 수 없다.
  대괄호는 전위=리터럴 / 후위=인스턴스화로 위치가 결정해 LL(1)이고 표기가
  하나다. 대가로 인덱싱 연산자를 두지 않는다.
- 파라미터 규칙을 callable 한정에서 전 파라미터로 일반화. 기본은 빌림,
  own만 소유 이전. capability를 예외로 두지 않는 이유는 capability의 존재가
  이미 타입과 effects 절에 드러나기 때문이다 — 표기가 실을 정보는 소유 이동뿐.
- 문 구분은 줄바꿈(Go식 자동 삽입), 블록은 식, return은 조기 탈출 전용.
  if/match를 식으로 두면 재대입이 줄어 move 검사가 단순해진다.
- match 가드 없음. 가드는 exhaustiveness를 흐리고 SMT 없이는 _ 분기를
  강요한다. 철학 1의 대표 항목을 문법 편의와 바꾸지 않는다.
- ?는 Result 전용 하드코딩. 조기 탈출도 블록 종료이므로 scope의 join/cancel이
  ? 경로에서도 실행된다. v1 linear 도입 시 이 경로가 암묵 drop 문제와 만난다.
- 수식어 순서는 바인딩(own, mut) 먼저, 타입(affine) 나중.

docs/grammar.ebnf는 LL(1)을 설계 제약으로 명시하고, effect 합집합을
결과 위치 전용 프로덕션으로 새겨 파라미터 위치의 역산을 파서가 거부하게 한다.
samples/는 확정 표기로 전면 갱신.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019ZVDeU6KLuUVL3gs18Hm3E

docs/thesis.md

@@ -66,15 +66,18 @@ Capability 전달 (Alias/Move 모델의 제3의 규칙):
      죽이므로 기각. 별도의 nonescaping 개념을 만들지 않고 use의 전염으로 정의해
      "한 개념 한 방식"을 지킨다 (Swift @noescape, second-class values의 검증된 경로)
 - 소유권 이전이 필요할 때만 명시적 move
-- 파라미터 위치의 callable은 기본이 use(비탈출)이고, 저장하는 쪽이 own fn으로
-  유표기한다. 파라미터 밖(반환 타입, struct 필드, channel 원소)의 callable은
-  use가 애초에 불가능한 위치이므로 무표기로 항상 owned 의미다
+- 파라미터 위치는 전부 기본이 use(빌림)이고, 소유 이전만 own으로 유표기한다.
+  capability든 callable이든 일반 affine 값이든 규칙은 하나다
   ※ 무표기-흔함 / 유표기-위험은 이미 언어의 다른 곳에 있는 규칙이다
      (effect 없는 함수가 무표기, effect 있는 쪽이 effects 유표기).
      새 조항이 아니라 같은 원칙의 적용이다
   ※ 반대로 두면 클로저를 저장하지 않는 고차 함수 — 즉 표준 라이브러리의 거의 전부 —
-     가 use 표기로 도배된다. 위험한 쪽(클로저를 오래 보관하는 sink)에 표기가 가야
+     가 표기로 도배된다. 위험한 쪽(소유를 가져가는 쪽)에 표기가 가야
      리뷰어의 눈이 그리로 간다
+  ※ capability를 별도 규칙으로 두지 않는 이유: capability의 존재는 이미 타입과
+     effects 절에 드러난다. 표기가 실어야 할 정보는 "소유가 옮겨가는가"뿐이다
+- 파라미터 밖(반환 타입, struct 필드, channel 원소)은 use가 애초에 불가능한
+  위치이므로 무표기로 항상 owned 의미다
 - capability가 셋 이상 필요하면 capability struct로 접는다 (표준 관용구):
       struct Deps { pay: PaymentGateway, log: Logger, db: Database }
   use deps: Deps로 받으면 affinity 전이와 use 규칙이 그대로 적용되므로
@@ -223,6 +226,28 @@ Generics (철학 2에서 파생):
 - coollang 단독 표기 (스탠퍼드 Cool과 구별, golang 방식 검색성 확보)
 - .cool (충돌 제로, 확장자 생략은 toolchain이 허용)
 
+표기 (철학 2,5에서 파생 — 문법 상세는 docs/grammar.ebnf):
+- 제네릭 인자는 대괄호 하나로 통일: List[a], map[Int, String](xs, f)
+  ※ <>는 식 위치에서 비교 연산자와 갈리지 않아 turbofish 같은 제2 표기를 부른다.
+     대괄호는 전위=리스트 리터럴 / 후위=인스턴스화로 위치가 결정하므로 LL(1)이고
+     표기가 하나로 끝난다. 대가로 인덱싱 연산자를 두지 않는다 (List.at을 쓴다)
+  ※ effect 규칙이 "합집합 위치에서는 명시적 인스턴스화 요구"이므로 식 위치의
+     인스턴스화 문법은 반드시 존재해야 한다. 추론으로 회피할 수 없다
+- 수식어 순서: 바인딩 수식어(own, mut)가 먼저, 타입 수식어(affine)가 뒤:
+  own affine fn(...) effects e -> b
+- 문 구분은 줄바꿈이다 (Go식 자동 삽입). 공식 formatter가 하나뿐이라 함정이 봉쇄된다
+- 블록은 식이다. 마지막 식이 블록의 값이고 return은 조기 탈출 전용
+  ※ if와 match가 식이면 let x = if c { a } else { b }를 재대입 없이 쓸 수 있다.
+     mutable 변수와 덮어쓰기가 줄면 move 검사가 그만큼 단순해진다 — 기준은 검증기다
+- match 가드는 v0에 없다
+  ※ 가드가 붙는 순간 그 분기가 패턴 전체를 덮는다고 말할 수 없어 exhaustiveness가
+     흐려지고, SMT 없이는 보수적으로 _ 분기를 강요하게 된다. 철학 1의 대표 항목을
+     문법 편의와 바꾸지 않는다. 필요하면 분기 본문에서 if를 쓴다
+- ?는 Result 전용으로 하드코딩한다 (trait solver가 없으므로 일반화 경로가 없다)
+  ※ 조기 탈출도 블록 종료이므로 scope의 join/cancel은 ? 경로에서도 실행된다
+  ※ v1에서 linear를 넣으면 ?의 조기 탈출 경로마다 해제가 필요해진다.
+     이것이 암묵 drop 문제와 만나는 지점이다 — linear 설계는 이 제약을 안고 시작한다
+
 ■ v0 — "기능의 서브셋, 아키텍처의 풀셋"
 목표: 시스템 속성(빠른 검증 루프)은 측정으로만 증명된다.
 성공 기준(숫자): 10만 줄 규모에서 함수 수정 시 check 50ms 이내.