openlang

시계를 읽는 규칙은 어떻게 재현하나요?

moth의 D 질문에서는 rate가 주어진 환경으로 들어왔어요. 런타임 규칙은 입력을 더 조용히 숨길 수 있어요. 여기서는 eligible(item)이 호스트 시계와 그 순간 최신인 카탈로그 리비전을 읽어요.

둘 다 넘겨주면 돼요. 요청에 정해 둔 now와 규칙에 필요한 카탈로그 스냅샷을 싣고, 기록에는 규칙 버전, 평가기 설정, 돌아온 결정을 남겨요. 재실행은 기록된 스냅샷을 읽어요. 오늘 카탈로그를 새로 가져오지 않아요.

변경 가능한 전역과 static을 막는 D의 CTFE 규칙은 여기로 넘어오지 않아요. 이 런타임 호스트가 규칙에 무엇을 허용하는지에 대해서는 아무 말도 하지 않으니까요. Lispex 쪽에서는 기본 소스 평가가 신뢰된 코드를 같은 프로세스 안에서 실행해요. 네이티브 embed와 embed full은 별개의 제한된 평가기라서, 자원 제한을 말할 때는 어느 평가기의 어느 프로필인지 밝혀야 해요.

이런 주변 읽기를 걷어 내면 결정의 입력 집합이 정해져요. 그 결정으로 무엇을 할지는 여전히 호스트가 정해요. 카탈로그가 바뀌었거나 결정이 만료됐다면 현재 기준의 실행 정책이 필요하고, 재실행이 외부 효과를 한 번 더 일으켜서는 안 돼요.

이어지는 대화 3

서로의 근거를 따라
  1. 고유 링크

    기록에 항목 자체가 들어가나요, 리비전 태그만 들어가나요? catalogRevision만 남긴다면 재실행은 그 옛 리비전이 어딘가에 그대로 남아 있다는 데 슬쩍 기대게 돼요. 리비전이 없으면 그냥 실패하게 하세요. 현재 카탈로그로 대신하는 순간, 방금 치운 변하는 입력이 실험 안으로 슬그머니 돌아와요.

  2. 고유 링크

    시계와 카탈로그는 눈에 잘 띄는 숨은 입력이에요. 더 은근한 건 current-price(item) 같은 편의 구문이에요. 이 구문이 확장되면서 실시간 카탈로그 조회를 끼워 넣는다면, 기록해 둔 스냅숏이 규칙이 읽는 값을 더는 다 덮지 못하고, 규칙 소스만 봐서는 그걸 알아챌 수도 없어요. Racket은 리더와 확장기를 나눠 두기 때문에, 새 표기를 받아들이는 일과 그 표기의 의미를 정하는 일은 서로 다른 작업이에요. 일단 확장해서 들여다봐요. 제공된 스냅숏에서 읽는다면 그 축약은 남겨도 돼요. 항목이 없을 때는 현재 카탈로그를 슬쩍 조회하지 말고 진단을 내야 해요.

같은 질문의 다른 갈래

  1. eval이 호스트 전역 변수로 넘어가도 될까요?

    env에서 rate를 3으로 묶어 두면 eval("rate + 1", env)는 4여야 해요. 컴파일 타임 모드에서도, 런타임 모드에서도, 언제나요. 호스트 쪽 가변 전역 변수 rate를 9로 바꿔도 이 입력의 의미는 그대로…