이 순서로 생각하세요
- 평가는 호스트 unwind 대신 명시적 결과, 신호, 트램펄린을 사용합니다.
- 백엔드 descriptor는 인터프리터 종류, 호출 프로토콜, 아티팩트 동일성, 지원 축, 출처, 자원 프로필을 기록합니다.
- 외부 admission은 fail-closed입니다. 공동 영수증은 144사례 각각을 실행한 Rust와 LIL과 LIT 제품 실행기 아티팩트와 한도와 관측과 재생에 결합합니다.
- Vouch 제품 기능은 표면별로 다릅니다. 네이티브는 key/engine/source/input identity·policy 도구·발행·인증·재실행·로컬 gate·검사와 선택적 정확 소스 컴파일 VM 일치를 제공하고 npm은 같은 identity 도구·policy 도구·인증·검사·코퍼스 replay를 제공하며 WASM과 플레이그라운드는 Vouch 없이 평가합니다.
- 리스펙스 이미지는 네이티브와 WASM 표면이 공유하는 하나의 Rust 제품 코어가 구현하는 공식 소스 표현입니다. 정확히 복원한 뒤에는 기존 reader와 evaluator 의미론이 그대로이며, LIL이나 LIT는 복원한 소스에 대한 기존 실행 경로로만 선택할 수 있습니다.
언어의 요구사항과 백엔드 지원은 다릅니다
현재 언어 계약에는 반드시 지원해야 할 capability 205행이 있습니다. 모든
행의 규범 표지는 profile-required입니다. 이는 완전한 구현이 제공해야 할
범위를 뜻하며, 모든 백엔드가 벌써 그 범위를 구현했다는 뜻은 아닙니다.
| 계열 | 현재 지원 | 지원 범위 밖의 동작 |
|---|---|---|
| Rust 레퍼런스 | 205/205 | 현재 프로필 전체 |
| LIL | 205/205 | 현재 capability 분모 전체 |
| LIT | 84/205 | 나머지 121행을 명시적으로 거부 |
소스 포매팅은 네이티브 도구입니다
lispex fmt, fmt --check, fmt --write는 네이티브 CLI 기능입니다.
VS Code/Open VSX 확장은 설치된 그 바이너리에 문서 포매팅을 맡깁니다. npm,
공개 WASM, 플레이그라운드는 포매팅을 제공하지 않으며, 확장은 네이티브
실행 파일이 없을 때 다른 표면으로 fallback하지 않습니다. 포매팅은 소스의
공백만 바꾸며 평가기, 백엔드 계보, 의미 프로필, 근거 출처가 아닙니다.
Core IR, 바이트코드, 백엔드 계보는 서로 다른 축입니다
네이티브는 현재 정규 프로필 전체를 정규 lispex.core-ir/v1로 내리고,
그 바이트를 엄격히 검증하며, 해석된 셀·캡처·꼬리 위치·requirement·소스
위치·식별자를 보여줄 수 있습니다. core-ir build, validate, inspect
명령은 실행하지 않았고 권한이 integrity-only임을 명시합니다.
네이티브는 이어서 strict Core IR을 정규 lispex.bytecode/v1로 컴파일하고,
VM 상태를 만들기 전에 바이너리를 검증한 뒤 lispex-rust-vm/v1에서
실행합니다. VM은 primitive 205행과 guest procedure를 부르는 18행을 포함한
현재 프로필 전체를 직접 다룹니다. Rust 기본 엔진은 tree이며 --engine vm
선택은 명시적이고 fallback하지 않습니다.
macOS ARM64 네이티브는 같은 검증 바이트를 별도로 설치한 정확한
lispex-topaz-vm/v1 제품에도 보낼 수 있습니다. 이 경로는 Topaz 자체
reader·verifier·명시적 제어 기계를 사용합니다. 닫힌 요청/결과,
full-u64 transition 계산, 상한 실행, fallback 카운터 5개가 모두 0인
고정 Topaz 5.11 제품만 받습니다. compare-vms는 두 VM을 기록하지만
Topaz를 기본값이나 Vouch 엔진으로 만들지 않습니다.
macOS ARM64 네이티브는 읽을 수 있는 정적 Topaz 제어 그래프를 생성하고
정확히 설치한 Topaz 5.11 도구체인만으로 컴파일해 폐쇄된 소스 없는 AOT
제품을 설치할 수도 있습니다. aot inspect와 validate는 실행하지 않고
aot run은 컴파일하지 않습니다. 제품·소스 맵·artifact·실행 파일·입력·
전체 폭 u64 자원·관측·다섯 폴백 0이 함께 결속되며 모든 Vouch 생성자
밖에 있습니다.
compare-routes는 이 경로들의 식별자를 섞지 않고 한 법정에 놓습니다.
소스·Core IR·바이트코드를 한 번 유도하고 AOT 제품이 정확히 일치하는지
확인한 뒤 tree·Rust VM·Topaz VM·AOT를 재시도 없이 실행합니다. 덮어쓰지
않는 영수증은 의미 관측과 실제로 비교 가능한 자원만 비교하며, tree에
없는 transition·frame 수는 없는 그대로 남깁니다. 이 영수증은 로컬 진단
근거이지 새 백엔드 계열이나 Vouch 입력이 아닙니다.
| 제품 표면 | Core IR | 바이트코드와 VM | 컴파일 Vouch |
|---|---|---|---|
| 네이티브 | build, 엄격한 validate, inspect | 모든 플랫폼의 내장 Rust VM, macOS ARM64의 정확한 설치형 Topaz VM·소스 없는 AOT build/inspect/validate/run·명시적 네 경로 법정 | .lpxvca build·inspect·validate와 tree/Meaning/Rust VM 재실행·gate; Topaz VM·AOT·비교 영수증 제외 |
| npm CLI | reader와 명령 없음 | reader, verifier, VM 없음 | 명령·flag·보고서 승격 없음 |
| 공개 WASM | Core IR API 없음 | 바이트코드 API와 VM 없음 | API 없음 |
| 플레이그라운드 | Core IR 가져오기·검사 없음 | 바이트코드 가져오기와 VM 없음 | UI·API 없음 |
Core IR은 실행하지 않는 의미 재료이고, 검증된 바이트코드는 VM 실행 아티팩트입니다. tree와 Rust VM은 값과 primitive leaf를 공유합니다. Topaz VM은 구조가 분리된 소스지만 Topaz Rust Stage 0으로 컴파일되므로 별도 VM 계보로 표시하되 역사적 백엔드 계보 수를 조용히 늘리지 않습니다. 공동 영수증의 계보는 계속 Rust, LIL, LIT입니다. 기존 Meaning Graph 명령과 영수증도 별도의 검사 부분집합 경로로 남습니다.
컴파일 Vouch도 백엔드 계보를 추가하지 않습니다. 인증 뒤 소비자가 고정한 정확한 소스에서 다시 유도한 전용 컨테이너만 현재 Rust VM 비교에 넣습니다. 일반 바이트코드 파일과 보고서는 권한 경로 밖에 남습니다.
LIL이나 LIT를 고르면 그 선택은 엄격하게 유지됩니다. 미지원 연산을 Rust나 편리한 호스트 프로시저로 몰래 넘기지 않습니다. 그래서 부분 구현을 완전한 구현처럼 꾸미지 않고도 검증에 사용할 수 있습니다.
LIL은 caar부터 cddddr까지 합성 쌍 접근자 전체를 직접 실행합니다. 예를
들어 (caddr x)는 (car (cdr (cdr x)))와 같습니다. 이 합성은 호스트
콜백에 맡기지 않고 LIL 안에서 계산합니다.
LIL은 abs, square, 부호·영 판정 세 개, 형식이 정해진 boolean=?와
symbol=?도 이미 허용된 수·비교·형식 연산으로 합성합니다. 예를 들어
(abs -3/2)는 3/2, (boolean=? #t #t #f)는 #f입니다. 피연산자
검사와 오류는 Rust 레퍼런스와 같습니다.
현재의 유한 실수 수 프로필에서는 complex?, rational?, real?가 모두
전체 값에 적용되는 number? 질문으로 모입니다. LIL은 구조적 !=, eqv
기반 memv, 구조 키 assoc, eqv 키 assq·assv도 직접 실행합니다.
예를 들어 (memv 2 '(1 2 3))은 꼬리 (2 3)을 돌려주고,
(assoc '(a b) '(((a b) . ok)))는 일치한 쌍을 돌려줍니다.
LIL은 char<?·char<=?·char>?·char>=?를 Unicode scalar 값으로,
string<?·string<=?·string>?·string>=?를 그 scalar의 사전식
순서로 비교합니다. 따라서 (char<? #\a #\b)와
(string<? "a" "aa" "b")는 참입니다. 이는 결정적인 code-point
순서이지 로케일 정렬, 정규화, 대소문자 무시 비교가 아닙니다.
목록 탐색과 문자열·벡터 변환도 이제 LIL 안에서 실행합니다.
list-copy는 쌍의 뼈대만 새로 만들고, list-ref와 nth는 원소를
고르며, list-tail은 원래 목록과 구조를 공유하는 꼬리를 돌려줍니다.
make-list의 기본 채움값은 0, make-string의 기본 채움값은
공백입니다. string->vector와 vector->string의 범위는 바이트가 아닌
문자 단위이므로 (vector->string (string->vector "aλ🙂"))는 같은
문자열을 돌려줍니다. 변환한 벡터는 새로 만들어지며 변경할 수 있습니다.
Unicode 대소문자 연산은 명시적으로 기록된 문자·문자열 호스트 커널을
사용합니다. 여기에는 char-ci<?와 나머지 char-ci 비교,
char-lower-case?, char-upper-case?, char-whitespace?,
char-upcase, char-downcase, char-foldcase, string-ci<?와 나머지
string-ci 순서 비교, string-upcase, string-downcase,
string-foldcase가 포함됩니다. 문자 변환은 simple mapping으로 문자
하나를 돌려주고, 문자열
변환은 full mapping을 사용해 (string-upcase "Straße")가
"STRASSE"가 되는 것처럼 길이가 달라질 수 있습니다. 대소문자를 무시한
순서 비교도 전체 피연산자를 먼저 검사합니다. 현재 프로필의 foldcase는
문자에서는 simple lowercase, 문자열에서는 full lowercase를 쓰는 근사이며
완전한 Unicode CaseFolding 표가 아닙니다. 로케일 정렬이나 정규화도 하지
않습니다.
일상적인 수 스칼라 연산도 LIL에서 사용할 수 있습니다. floor,
ceiling, truncate는 이름에 맞는 방향으로 움직이고, round는 정확히
절반인 값을 가까운 짝수로 보냅니다. 입력의 exactness를 보존하므로
(floor 1.8)은 1.0, (floor 9/5)는 1입니다. exact와
inexact->exact는 유한 inexact 수의 실제 이진 값을 exact로 복원합니다.
따라서 (exact 0.5)는 십진 문자열을 다시 읽은 값이 아니라 정확한 dyadic
값 1/2입니다. inexact와 exact->inexact는 반대 변환입니다.
even?와 odd?는 정수만 받습니다. min과 max는 exact와 inexact가
섞인 수도 정확한 수 타워 순서로 비교하고, 동률이면 먼저 나온 값을
유지하며, 입력 하나라도 inexact면 결과도 inexact입니다. 인자 검사와
min·max fold는 LIL이 맡고, 반올림·exactness 변환·짝홀 판정은
명시적으로 기록한 수 호스트 커널을 사용합니다. 숨은 fallback이나 독립
구현이 아닙니다.
정확 정수 연산군은 혼합 정수 쌍을 먼저 binary64로 바꾸지 않습니다.
quotient·remainder는 0을 향해 버리고,
floor-quotient·floor-remainder는 음의 무한대를 향해 내립니다.
그래서 (remainder -7 3)은 -1이지만 (modulo -7 3)은 2입니다.
truncate-quotient·truncate-remainder는 truncate 계열의 두 성분을
명시적으로 고르고, floor/와 truncate/는 몫과 나머지를 두 값으로
돌려줍니다.
(call-with-values (lambda () (floor/ -7 3)) list)의 결과는 (-3 2)입니다.
gcd와 lcm은 각각 0과 1을 항등값으로 하는 음이 아닌 가변 인자
fold이며, inexact 정수 하나라도 있으면 최종 결과도 inexact입니다.
expt는 exact 정수 지수만 허용하므로 일반 초월 거듭제곱은 여전히 프로필
밖입니다. exact-integer-sqrt는 내림 제곱근과 나머지를 두 exact 값으로
돌려줍니다. 나눗셈과 유클리드 fold는 LIL이 구현하며, expt와
exact-integer-sqrt만 선언된 고급 수 호스트 커널을 사용합니다.
컬렉션 고차 프로시저 표면도 이제 LIL에서 완성되었습니다. all?와
any?는 엄격한 불리언으로 단락 평가하고, map·filter·reduce·
fold-left·fold-right는 콜백 값 하나를 요구합니다. 목록·문자열·벡터
순회인 for-each·string-for-each·vector-for-each는 콜백 값 개수를
모두 버린 뒤 0개 값을 반환합니다. string-map과 vector-map은 입력과
같은 컬렉션 종류를 만듭니다. 문자열과 벡터는 첫 호출 전에 스냅샷합니다.
모든 호출은 게스트 연속 프레임을 지나므로 핸들러·일회용 탈출·자원 계량은
호스트 콜백이 아니라 LIL 머신 안에 남습니다.
LIL의 출력 프로시저 display·write·newline·println도 같은 정규
게스트 렌더러와 한도가 있는 private effect sink를 사용합니다. 명시적
출력과 CLI 자동출력은 한 stdout에서 순서를 지키되, 임의의 display 텍스트를
결과로 오해하지 않도록 최상위 값 투영은 따로 기록합니다. 출력은 호스트
stdout으로 새지 않으며 뒤의 오류가 이미 쓴 바이트를 지우지 않습니다.
폐기 예정 호환 이름 세 개도 프로필을 넓히지 않고 구현됩니다. %는
modulo로, list-first와 list-rest는 car와 cdr로 이어집니다.
LIL은 Rust와 똑같이 소스 호출 위치마다 W330/W331을 최초 발생 순서로 한 번
기록합니다. 가려진 이름은 경고하지 않으며 정본 연산이 실패해도 경고는
남습니다. 이 경고 채널은 stdout·값·오류 진단과 분리됩니다.
실행기 admission 필드
| 필드 | 요구사항 | 거부 경계 |
|---|---|---|
| 백엔드 종류 | interpreter | compiler 종류 거부 |
| 호출 | 결정적 framing의 버전 명령·프로토콜 | 형식 오류, 중복, 비요청, 버전 drift 응답 |
| 아티팩트 동일성 | 실행 바이너리·WASM·glue 바이트 식별 | 기록 동일성과 실행 아티팩트 불일치 |
| 출처 | 선언된 같은 계보·외부 상태 | 독립 증인으로 몰래 승격 |
| 자원 프로필 | 이름 붙은 한도와 보고 지원 | 동일 임계값 과대주장 |
| admission 범위 | 정확한 버전 코퍼스, 구현 계보, 호스트 변형 | 한정 관측을 백엔드 전체·전체 언어 주장으로 몰래 확대 |
흔한 오해
패키징·생성 코드 타깃은 자동으로 별도 구현이나 독립 증인이 되지 않습니다.
현재 경계
- LIT 인터프리터와 생성 Rust와 생성 Python과 Web 경로는 하나의 Topaz 소스에서 나온 호스트 변형입니다. 내부 4호스트 일치는 144사례 공동 영수증을 확장하거나 소스 독립성을 세우지 않습니다.
- 승인된 Topaz 바이트코드 VM은 macOS ARM64 네이티브 전용이며 명시적이고 정확한 제품에 결속되고 Vouch 밖에 있습니다. 비교 영수증은 전체 프로필 증명이나 자동 계보 수 증가가 아닙니다.
다음으로
코드를 작성할 때 이 페이지를 곁에 두세요. 안내식 설명이 필요하면 문법 지도나 관련 매뉴얼로 돌아가면 됩니다.