일본어를 쳐 본다
시리즈 최저가의 probe: 언어에 일본어를 쳐 넣고, 각 조작이 무엇을 하는지 보고한다. byte 지향의 str은 정직하고 문서화된 결정이었다 —— 다섯 글자 인사에 길이 15는 옳다, 다만 텍스트 프로그램이 원하는 답이 아니다. probe는 모든 「틀린」 답을 두 상자로 분류했다: byte면 되니까 되는 것, codepoint view가 필요한 것. 수정은 의도적으로 작게 —— UTF-8 경계를 존중하는 두 builtin, 그 위의 세 prelude 합성 —— 그리고 우연히 역사적이었다: 같은 릴리스에서 4 backend 전부에 태어난 첫 기능.
이 probe는 시리즈의 어느 것보다 쌌다: 다섯 글자의 일본어 인사를 받아 문자열 라이브러리를
한 바퀴 돌리는 십수 줄. 서버도, 게임도, 벤치마크도 없음 —— 그저 언어에 일본어를 쳐 넣고,
돌아온 것을 적는다. 결과는 「기록할 가치가 있다」는 종류의 예측대로였다. str_len은 15라고
말했다. index는 \xe3라고 말했다. 반전은 어느 언어의 텍스트도 아닌 쓰레기를 낳았다.
substring은 글자를 반으로 잘랐다. 어느 것도 버그가 아니다: memory-model의 docs는 str은
byte라고 명기하고, 모든 조작은 약속대로의 일을 엄밀히 했다. 하지만 「문서화됨」과 「텍스트에
쓸 수 있음」은 다른 성질이고, 작자가 일본어로 쓰는 언어는 이 릴리스까지 こんにちは의 글자
수를 셀 방법을 갖지 않았다.
두 상자
probe의 유용한 한 수는 「틀림」을 한 무더기로 다루기를 거부한 것이다. 놀라운 답은 각각 두 상자 중 하나에 들어갔다. 상자 하나: byte가 옳은 답. 연결, 등치, 해시, ASCII 구분자 split, 버퍼 크기용 byte 길이 —— UTF-8은 이것들이 날 byte로 동작하도록 설계되어 있고, probe는 각각을 일본어 문자열에 대해 검증했다. 수정 불요. 정직한 주기는 「이것들은 처음부터 망가져 있지 않았다」. 상자 둘: 프로그램의 뜻은 글자. 「몇 글자인가」로서의 길이, 「n번째 글자」로서의 index, substring, 반전. 이것들은 codepoint view가 필요하고, user code로 꾸며내는 것은 bitwise 연산자가 없는 언어에서 UTF-8의 lead-byte 디코드를 재구현함을 뜻한다 —— probe는 시도했고, div와 mod로 세운 40줄 디코더를 낳았고, 그 추함을 forcing measurement로 철했다.
최소의 정직한 수정
설계의 물음은 스코프였다: 완전한 Unicode 층 —— grapheme cluster, 정규화, locale 대응
collation —— 인가, codepoint view인가? 답은 상자에서 왔다: 상자 둘의 전부는 codepoint로
풀리고, probe의 무엇도 grapheme을 요하지 않았다. 그래서 릴리스는 정확히 두 builtin을 더했다:
utf8_len, 그리고 문자열을 단일 codepoint 문자열의 리스트로 분해하는 utf8_chars. 나머지
전부 —— n번째 글자, codepoint 안전한 substring, 반전 —— 는 Mere 자신으로 쓰인, 위에 합성하는
세 개의 짧은 prelude 함수다. str은 byte 그대로. codepoint view는 철자로 opt-in한다. 우연의
이정표: prelude는 어디서나 돌아야 하므로, 두 builtin은 4 backend 전부 —— interpreter, C,
wasm, LLVM —— 에 같은 릴리스로 착지해야 했다. 프로젝트 사상 첫, 모든 곳 동시에 태어난
기능이다. 그것을 강제한 규칙(「prelude는 universal한 builtin만 써도 된다」)은, 공급할 수 없는
prelude로 LLVM backend가 크래시한다는 아픈 길로 발견되었다. こんにちは의 길이는 이제 5, 반전은
はちにんこ, 그리고 남은 gap —— grapheme, は + 결합 기호가 아직 2 codepoint인 세계 —— 는 docs의,
프로그램이 필요로 하기를 기다리는 다른 gap들 옆에 적혀 있다.