십육진을 읽게 되다

Part는 그 안에서 가장 작은 변경으로 닫는다. 여기서 끝내는 의도는, 그 작음이야말로, 도달에 여섯 릴리스가 걸린 이유라는 데 있다. 이것은 papercut에 대한 이야기다: 언제 무시하고, 언제 수정할 값어치가 되었는가.

같은 돌에, 두 번

papercut은 버그가 아니다. 프로그램은 compile되고, 돌고, 올바른 답을 낸다. 그저 도중의 무언가가 쓸데없이 어색하다. 언어는 수의 lexer에 하나를 안고 있었다: 0xFF는 16진 정수 255로 읽히지 않았다. 정수 0 직후에 xFF라는 식별자, 로 읽혔으므로, 그것을 쓰는 줄은 나중에 “unbound variable: xFF”로 실패했다 —— 원인에서 멀리 떨어진 헷갈리는 에러다. 우회는 자명하다: 손으로 10진으로 변환해 255라 쓴다. 그래서 오랫동안 아무도 고치지 않았다. 아무도 16진 리터럴을 칠 이유가 없었기 때문이다.

그러다 바로 이 Part에서 두 개의 probe가, 연달아 쳤다. SHA-256에는 명세서가 16진으로 열거하는 64개의 round 상수가 있고, 그것들은 10진으로 코드에 들어갔다. East Asian Width 표는 모든 차트가 16진으로 쓰는 Unicode 블록 경계의 열이고, 그것들은 10진 레인지로 들어갔다. 둘 다 동작했다. 둘 다, 있어야 할 것보다 소스와 대조하기 어려웠다. 코드를 명세와 비교하는 독자가, 모든 수를 머릿속에서 변환해야 했기 때문이다. 한 probe가 16진을 10진으로 쓰는 것은 어깨를 으쓱하는 이야기. 두 번 연속은 측정값이다. 한 번 걸리는 papercut은 소음. 두 번 걸리는 papercut은, 둘 다 레퍼런스에서 베껴 쓰면서, 언어가 진짜 종류의 프로그램과 스치는 곳을 알려준다.

한 분기와, 그 값

수정은 lexer의 한 분기다: 0 뒤에 x나 X와 16진 숫자가 이어지면, 16진 숫자를 소비해 변환한다. 0xFF와 0Xff는 이제 평범한 정수로 lex된다 —— 새 타입은 없고, 다른 정수 리터럴과 같은 backend별 폭 —— 그리고 16진 숫자 없는 맨 0x는 아직 0 + 식별자 x로 읽히므로, 전에 동작하던 것은 아무 것도 깨지지 않는다. 8진도, 2진도, 자릿수 구분자도 없다. 어느 것도 아직 두 번 요구되지 않았다. 눈에 보이는 값은, 그것을 주장한 두 probe로 곧장 돌아갔다: SHA-256 example의 64개 round 상수와 8개 초기 해시 값은 이제 16진으로, 공개된 명세와 줄마다 일치하고, 체크섬 도구의 다항식과 마스크도 16진이다 —— 그리고 둘 다 아직 레퍼런스 vector와 일치한다. 그것이 변경의 논거 전부다: 언어가 이 프로그램들을 전에 표현할 수 없었다, 가 아니라, 이제 그것들이 베껴진 문서처럼 읽힌다, 이다.

장부

하루에 여섯 릴리스, 네 개의 작은 프로그램에서, 그 형태는 분명히 말할 값어치가 있다. 정수의 폭과 bitwise 연산자는 물음과 그 답이었다 —— 연산자를 필요로 한 probe가, 그 아래의 폭 문제를 먼저 찾았다. 바이트 reader와 바이트 writer는 같은 문의 두 절반. Mandelbrot 렌더러는 문서가 언어에 유리하게 거짓말하는 것을 찾았고, 이 마지막 하나는 crypto와 Unicode probe가 둘 다 느낀 마찰을 고쳤다. 그 모든 것 아래에 있는 것은 한 문장이다: backend가 넷인 언어는 실은, 네 구현이 같은 이야기를 계속 말하게 하는 약속이고, 이야기가 갈라지는 곳을 찾는 가장 싼 방법은, 바로 그 한 점에 닿는 작은 진짜 프로그램을 쓰는 것이다 —— 해시, 체크섬, 그림, 테이블 —— 그리고 각 backend가 돌려주는 답을 읽는다. probe는 쌌다. 그것들이 비교한 진실은 싸지 않았다. 방법이 다음에 어디로 갈지는, 언제나처럼, 아직 정해지지 않았다 —— 그것이야말로 요점이다.