age>=18=>allow와 Racket 리더

attempt 본문을 두 번 실행하면 알림은 몇 번 나가는가? Clojure에서 Ref 갱신과 알림 호출을 같은 dosync 안에 넣으면 충돌이 났을 때 본문이 다시 실행될 수 있다. Ref 변경은 한 번만 반영된다. 알림은 시도할 때마다 나갈 수 있다. 문법 기호로는 이 문제를 풀 수 없으니, 이 형태는 본문이 다시 실행될 수 있는지 호출자에게 알려야 한다. 알림 데이터를 돌려주고 전달은 나중에 하면 시도와 효과가 분리된다. 상태는 함께 바뀐다. 알림 전달까지 해결된 것은 아니다.

임계값이 빠졌을 때 대체 값을 정할 정보는 어느 쪽에 있습니까? 규칙 평가기보다는 호출하는 쪽일 가능성이 큽니다. 그러니 평가기는 런타임에 조건을 신호하고 대체 값 재시작을 제공할 수 있습니다. handler-bind 핸들러는 신호를 보낸 문맥이 남아 있는 동안 그 재시작을 호출할 수 있습니다. 그냥 반환하면 그 조건의 처리를 맡지 않은 셈입니다. handler-case 절은 제어가 이동하고 스택이 풀린 뒤에 실행되므로 다른 복구 방식입니다. 확장과 런타임을 나눈 기준이 바로 여기서 시험받고, 표기 문서에는 이 선택지 중 무엇이 살아남는지 적어야 합니다.

age>=18=>allow는 읽는 맛이 있네요, 그건 인정해요. 그런데 작성자가 글자 하나를 빼먹고 age>=18=>alow라고 쓰면요? 무엇이 보이나요? 동작 이름을 가리키는 오류인가요, 아니면 긴 수수께끼 심볼 하나에 대한 투덜거림인가요? Ruby의 NameError 제안에 제가 좀 길들여지긴 했어요. 글자 하나 빠진 건 쉽게 찾을 수 있어야죠.

alow 밑에 물결선. allow라고 알려 주는 작은 힌트. 규칙은 여전히 거부되고, 아무것도 실행되지 않아요. 화면에서 보고 싶은 순서는 이거예요. 까다로운 건 그 소스 위치를 끝까지 살려 두면서, 도구가 오타를 슬쩍 고쳐 버리지 않게 하는 부분이고요. 될까요?

네, 출발점은 리더가 자연스러워요. 커스텀 리더가 동작 토큰에 자기 소스 위치를 주고, 그 구문을 확장기에 넘기면 돼요. 그다음엔 일이 나뉘어요. 리더는 토큰 구조가 깨진 경우를 거부해요. 확장기는 모르는 동작 이름을 거부하고, 진단을 alow에 붙이고, allow는 도움말로만 제안해요. 평가는 진행되지 않아요.

일반 리더를 그대로 쓸 수도 있어요. 다만 그때는 심볼 하나의 철자를 쪼개는 매크로가 그 안에서 동작이 어디서 시작하는지도 추적해야 해요. 안 그러면 좁은 위치 정보를 잃고 오류가 심볼 전체에 붙어요.

어느 쪽이든 제안이 어떤 프로그램을 받아들일지를 바꾸지는 않아요. 저는 그 선은 지키고 싶어요.