v1.2.0 — do … end 는 짝인 괄호, 검사가 안 닿던 자리 둘

무엇이 바뀌었나

이 판은 둘을 고친다 — 문법의 닫는 규칙과 검사가 안 닿던 자리.
언어 개정 1.1 → 1.2(깨지는 변경 하나), 알려진 결함 2 → 0.

⚠ 깨지는 변경 — do … end 는 짝인 괄호다: end 는 자기 do 만 닫는다

end 는 이제 { } 의 } 처럼 자기 do 만 닫는다. 바깥 요소는 제 닫개를 스스로 챙긴다.

rem 블록을 몸으로 갖는 구문은 블록에서 끝난다 — 뒤에 점을 찍지 않는다
if eq a 0 . do return 1 . end else do return 2 . end

rem 블록을 품은 값을 쓰는 문장은 자기 점으로 닫는다
let p pt be make pt do x 1 . end .

경우	쓰는 법	어기면
블록을 몸으로 갖는 구문 (fn if else while for match case struct enum region borrow pipe …)	블록이 끝나면 끝난다	뒤에 점을 찍으면 E-DOT-STRAY
블록을 품은 값을 쓰는 문장 (let … be make T do … end ., return pipe xs do … end .)	자기 점으로 닫는다. 괄호 안이면 ) 가 닫는다	E-DOT-MISSING
블록 안의 문장 · 열거형 갈래	저마다 자기 점으로 닫는다 (end 가 대신 닫지 않는다)	E-DOT-MISSING
머리 없이 홀로 선 do … end	쓸 수 없다	E-BLOCK-NOHEAD

• 전엔 end . 와 end 가 같은 뜻의 두 철자였다 — 처리기가 뒤의 점을 빈 폼으로 조용히 버렸다.
  그리고 let … be make T do … end 의 end 하나가 make 의 블록과 let 문장을 함께 끝냈다.
• 머리 없는 블록은 전엔 --check 를 통과하고 실행되지 않았다.
• 서식기(--fmt)도 이 규칙으로 쓴다.
• 이 저장소의 코드·문서·시험 전부를 옮겼다. 옮기기 전과 뒤에 방출 C 가 973 파일 모두 바이트 동일하다.
• 정본 §6.1.6 (2)–(2d) 와 부록 A 에 적혀 있고 거부 예제가 붙어 있다.
• 범위 밖: 타입을 겹쳐 닫는 점(slice u8 . .)과 괄호 안 점((mul a 2 .))은 아직 그대로 선다.

고침 — guard … else 가 타입 검사 밖이었다

output result … 인 op 이 guard … else return 0 . 처럼 맨값을 돌려줘도 --check 가 초록이었고,
실행하면 두 뒤끝 다 멈췄다. guard 의 else 가 통째로 검사 밖이었기 때문이다(그 블록 안의 let z u8 be 300 조차 통과했다).

• 이제 else 뒤의 한 문장과 블록 전체가 타입 검사를 받는다(E-TYPE-RETURN 등).
• return <op> 으로 다른 op 의 실패를 넘기면 try 와 똑같은 errors 닫힘을 따른다(E-ERR-UNDECLARED).
• errors 절이 없는 op 을 try·return 으로 넘기면 그 op 의 오류 타입 전체를 기준으로 본다(전엔 아무것도 대조하지 않았다).
• 이 검사가 라이브러리의 버그 하나를 드러냈다: lib/random.low 의 seed_from_os 가 output u64 인데 return ok 0 을 내고 있었다.

고침 — link "…" 절이 거짓 E-VISIBILITY 를 냈다

link "…" 가 붙은 export op 을, link 라는 이름의 op 을 가진 모듈이 부르면 «export 안 된 이름» 이라는 틀린 진단이 났다.
가시성 검사가 op 머리의 절 낱말 link 를 그 모듈의 비공개 op 이름으로 읽었다. 이제 op 머리의 절 낱말은 이름 참조로 보지 않는다.

확인

• 골든 2,060 / 2,060 · 단위 시험 전부 통과 · 매뉴얼 예제 476 · 정본 예제 129.
• ★ 이 저장소의 크립토는 상수시간을 약속하지 않고 감사받지 않았다.