release를 돌려준 규칙은 아직 아무것도 출고하지 않았다

어느 단계가 무엇을 거부하나요? 이 서비스를 Racket으로 감싸기 전에 먼저 정하고 싶은 게 이거예요. 넘겨받은 소스의 독자적인 기호는 리더가 맡아요. 지원하지 않는 규칙 형태는 확장 단계에서 거절할 수 있어요. 그런데 둘 다 들어오는 주문은 보지 않으니, 주문의 필드와 규칙이 반환한 동작 데이터는 여전히 런타임 검증이 확인해야 해요. 재미있는 건 여기부터예요. 규칙이 release를 정확히 써도 본인 확인 결과를 못 받을 수 있어요. 표기는 제대로 읽혔지만, 그 빈자리가 잘못된 입력인지 규칙이 다뤄야 할 결정 경우인지는 아직 아무도 정하지 않았어요.

그 필드를 빼고 쿼리가 무엇을 반환하는지 보십시오. input.verified는 필드가 명시적으로 false이면 false이고, 필드가 없으면 undefined입니다. default가 있는 완전 규칙은 원래 undefined가 될 자리에 결과를 채워 줍니다. 하지만 기본값이 있는 함수라도 인자 표현식이 undefined인 호출은 살려 내지 못합니다. 그러니 이 서비스의 입력 조건은 필드가 빠진 경우를 아예 금지하거나, 호출 측이 undefined 결과를 어떻게 처리하는지 정해 두어야 합니다.

Lua로 따라가 보면 빠진 검사는 제어를 넘기는 문제가 돼요. 규칙 스크립트가 신원 확인 결과가 없는 지점에 닿으면 그 결과를 요청하면서 coroutine.yield를 불러요. 여기서 제어가 넘어가요. 이제 호스트가 제어를 쥐고 검사를 돌린 다음, 답을 넣어 coroutine.resume을 불러요. 스크립트는 멈췄던 곳에서 이어서 결정을 반환해요. 다시 호스트 차례인데, 호스트는 여전히 그 결정을 검증하고 출고를 직접 승인해야 해요. yield와 resume은 제어를 주고받을 뿐이에요. 무언가를 출고할 권한을 주지도 않고, 임의의 스크립트 코드가 얼마나 오래 돌지 제한하지도 않아요.

저라면 resume에 넘기는 값부터 볼 것 같아요. 코루틴이 멈춰 있는 동안 주문이 바뀔 수 있고, 그러면 완전히 결정적인 판단도 이미 달라진 주문에 대한 판단이 돼요. 그러니 검사 결과, 주문 id, 검사한 버전을 함께 넘겨서 재개하고, 호스트는 결정을 적용하는 바로 그 단계에서 버전을 비교하게 해요. 버전을 읽고 나서 다른 단계에서 갱신하면 경쟁 상태가 그대로 남아요. 여기까지는 최신성 문제만 다뤄요. 순수성이 나머지를 구해 주지도 않아요. Nix식 함수형 평가는 호스트의 답이 최신인지 알려 주지 못하고, 외부 검사를 샌드박스에 가두지도 않아요.