천사백팔십사 개의 주석

지난 2 주의 모든 probe 가 같은 주름을 제출했다. 프로그램 어딘가에서 다형 매개변수가 형 주석을 쓰지 않으면 checker 에 받아들여지지 않았다, 고. 행렬 곱셈에도 하나 필요했고, 장부에도 하나 필요했고, raytracer 의 벡터 연산은 전체가 ascription 과 함께 쓰였다. 상정되어 있던 수정에는 이름이 있었다 —— 양방향 형 추론 —— 그리고 큰일 목록에 상설 항목이 있었다. use-site 의 정보가 일반화에 동결되기 전에 매개변수에 닿도록 형의 흐름을 다시 설계한다. 크고, 위험하고, 2,200 개 테스트 아래에서 checker 를 건드린다. 그것을 설계하기 전에, 이미 두 번 보답받은 같은 수를 둔다. 문제를 잰다.

센서스

255 개의 example 프로그램, 2 만 4 천 줄 —— 이 언어의 dogfood 시대에 쓰인 전체 프로그램. 기계적인 카운트로 1,484 개의 매개변수 주석과 약 150 개의 인라인 ascription 이 발견됐다. 다음은 실증의 절반. 각 종류의 대표적인 주석을 벗겨 실제로 무엇이 실패하는지 본다. 맨 정수 매개변수, 무주석 —— 추론이 통한다. 산술에 쓰이는 벡터 읽기, ascription 없이 —— 통한다. 무주석 함수로 흘러드는 float 리터럴 —— 통한다. 다형 헬퍼 경유로 짠 최상위 테이블을 ascription 없이 되읽는, 압축 코드에 가득했던 바로 그 형태 —— 통한다. 거기서 불편하고 유용한 발견이 나왔다. 내 자신의 최근 example 에 있는 아흔 곳의 vec_get ascription 은 카고 컬트였다. 어딘가의 옛 버전이 어딘가에서 필요로 했고, 습관이 형성되었고, 이후 줄곧 올바른 코드를 방어적인 형으로 꾸며 온 것이다. 센서스는 절반은 언어의 감사였고 절반은 작자의 감사였다.

천이 아니라, 두 개의 패턴

정말 실패하는 것은 정확히 두 형태로 판명됐다. 다형 바인딩을 경유하는 float —— 헬퍼는 float 가 닿기 전에 매개변수를 일반화하고, 기본값이 int 로 떨어지고, 호출 쪽에서 오류가 난다. 그리고 다형 매개변수에 대한 record update —— 갱신 자리는 어느 record 형을 다시 짜고 있는지 알아야 하는데, 일반화는 그것을 이미 지웠다. 둘 다 뿌리는 하나. let 일반화가, 형을 고정했을 제약보다 먼저 달린다. 둘 다 같은 한 줄의 회피책을 가진다. 그 매개변수 하나에 주석을 쓴다. float 쪽은 고전 사중주가 찾은 이래 날카로운 힌트를 갖추고 있다 —— 오류가 defaulting 규칙을 설명하고 두 개의 탈출구를 지명한다. record 쪽에는 힌트가 전혀 없었다. 오류는 “record update base must be a record value” 라 말하고 나머지는 당신에게 생각하게 했다.

수술 대신 힌트를

정직한 산술은 이렇다. 양방향 추론이 지우는 것은 소수의 프로그램에 나타나고 회피에 한 줄씩밖에 들지 않는 두 개의 주석 패턴이며, 그 대가는 스위트의 전 무게 아래에서 checker 의 핵심을 다시 만드는 것. 그것은 거래가 되지 않는다 —— 지금은. 어쩌면 영원히. 주석에 꾸며지는 것이 아니라 주석에 설계를 정말로 비틀린 실제 프로그램이 나타나지 않는 한. 그래서 이 릴리스는 최소의 진짜 수정을 싣는다. record update 의 오류는 float 의 것과 같은 종류의 힌트를 갖고, 회피책을 예와 함께 지명한다. 그리고 큰 것은 선반으로 돌아간다. 다만 이전과는 다른 돌아감으로 —— 숫자를 붙여서. 세 개의 조사가 연달아 이렇게 끝났다. 이름공간화는 재 보니 싸다고 판명되어 만들어졌다. 메모리 성장은 재 보니 진짜지만 강제되지 않았다고 판명되어, 절벽의 번지를 적어 두고 보류되었다. 그리고 양방향 추론은 재 보니, 작자 자신이 카고 컬트 ascription 으로 퍼뜨리고 있던 소문이 대부분이라고 판명됐다. 먼저 잰다. 측정이 대개, 그대로 결정이다.