aboutsummaryrefslogtreecommitdiffstats
path: root/docs/design
diff options
context:
space:
mode:
Diffstat (limited to 'docs/design')
-rw-r--r--docs/design/008-module-format.md3
-rw-r--r--docs/design/027-computation-core.md26
2 files changed, 28 insertions, 1 deletions
diff --git a/docs/design/008-module-format.md b/docs/design/008-module-format.md
index dde292e..201baf9 100644
--- a/docs/design/008-module-format.md
+++ b/docs/design/008-module-format.md
@@ -36,7 +36,7 @@ v7은 027의 4단계(패턴 모으기)의 판이다. 4b로 **키별 문서**를
인자 셋이고, 키의 누름과 뗌, text 입력, 타이머, frame, 가리킴은 메시지 입력의 묶음(무엇이 그 메시지를 만드는가)이다. 핸들러의
이벤트는 그 입력의 번호이고, DT와 TEXT_INPUT은 필드 읽기(FIELD)가 대신한다(아래 표의 번호가 당겨졌다). 4e로 **보기가 아무 값**이 되었다: 보기와 열의 타입이
레코드 필드의 것(바이트와 리스트가 더해졌다)이고, 표는 리스트 보기다. 리스트 보기는 리스트 상태 그대로나 그 지도, 또는 블록이
-낸 리스트를 행으로 가지며, 보기 항목은 20바이트다. 4단계가 끝날 때까지 v7은 걸음마다 바뀐다(1.0 전, 생산자는 aup 하나다).
+낸 리스트를 행으로 가지며, 보기 항목은 20바이트다. 5단계(수의 모델)로 내림한 몫(FLOORDIV, 95)이 더해졌다. 4단계가 끝날 때까지 v7은 걸음마다 바뀐다(1.0 전, 생산자는 aup 하나다).
**레코드 안의 리스트**(027의 2b).
- 레코드 필드의 타입 4(LIST)는 항목들의 레코드를 기본값 자리(i64)에 둔다.
@@ -181,6 +181,7 @@ v7은 027의 4단계(패턴 모으기)의 판이다. 4b로 **키별 문서**를
| 92 | RETURN | … r… → | 함수 `인자`(자신)를 끝낸다. 맨 위의 결과가 부른 쪽으로 간다 |
| 93 | CHAR_AT | t q → q | text의 바이트 자리 q(i64)에서 시작하는 글자의 코드 포인트(i64). 글자가 시작하지 않는 자리나 밖이면 `limit` |
| 94 | CHAR | q → t | 코드 포인트 하나의 text. 0–0x10FFFF 밖이면 `limit`, 서로게이트면 `encoding` |
+| 95 | FLOORDIV | n n → n | 내림한 몫(027의 5단계): MOD의 나머지를 뺀 a를 b로 나눈 것을 가까운 정수로(파이썬의 float `//`와 같다. `1 // 0.1`은 9). 0의 부호는 a / b의 것. 0으로 나누면 `divide` |
bool은 실행 중에 수의 칸에 든 0이나 1이고, i64는 같은 8바이트의 정수다. CONST의 인자 2는 i64 상수(값의 8바이트), NUM_TEXT의
인자 2는 i64의 10진 글자다. LOAD·STORE·지역 칸·항목·FIELD·SEND는 i64를 수처럼 옮긴다. FOLD의 종류에 64(PURE_FOLD_INTEGER)를
diff --git a/docs/design/027-computation-core.md b/docs/design/027-computation-core.md
index 28c03b2..4c7fb60 100644
--- a/docs/design/027-computation-core.md
+++ b/docs/design/027-computation-core.md
@@ -513,6 +513,32 @@
- 정수 리터럴의 기본, `/`와 `//`, 돈의 십진수, 묶음 실행기의 2^53 검사를 정한다.
- **막대.** TPC-C가 SQLite와 행마다 같은 상태를 남기는 것이 그대로다.
+- **설계(2026-10-19).**
+ - **두 수.** `number`는 binary64이고 리터럴과 셈(개수, 자리, 길이, u32 필드)의 기본이다. 정수는 정수인 number이고 2^53까지 정확하다.
+ `i64`는 정확한 정수의 타입이다: 2^53을 넘는 정수, 비트, 돈. 둘은 섞이지 않는다. 옮기기는 `number(i)`(정확할 때만, 넘으면
+ `limit`)와 `i64(x)`(정수이고 범위 안일 때만)다. 리터럴은 맥락을 따른다(i64가 오는 자리의 `1`은 i64).
+ - 왜 i64가 기본이 아닌가: 개수·자리·길이·u32 필드가 모두 number라서, 리터럴만 i64로 하면 `n = xs.count` 같은 줄마다 옮기기가
+ 든다. 그것들을 모두 i64로 하면 묶음 실행기와 JIT의 수의 길(binary64 레인)을 i64로 다시 지어야 한다. 앱의 셈은 거의 2^53 안이고,
+ 그 밖은 i64가 맡는다. 한 기본 타입이 압축이다.
+ - **나눗셈.** `/`는 number의 나눗셈이다(i64끼리는 거절: `//`를 쓰거나 옮긴다). `//`는 내림한 몫이다: number는 파이썬의 그것과
+ 같은 정확한 내림(나머지를 빼고 나눈다), i64는 I64_DIV. `%`는 그 짝(내림한 나머지, 나누는 수의 부호)으로 이미 있다.
+ - **접기.** i64의 합은 정확하게 셈하고 결과만 범위를 본다(중간이 넘쳐도 끝이 i64 안이면 답이다): 차례에 매이지 않는다. number의
+ 합은 차례대로의 왼쪽 접기이고, 구현은 답이 같을 때만 차례를 바꾼다. 묶음 실행기의 2^53 검사가 그 조건이다: 모든 항이 정수이고
+ 그 크기의 합이 2^53 아래면 어느 차례든 정확하다. 아니면 차례대로다.
+ - **돈.** 새 타입 없이 i64의 최소 단위(센트)다. 셈은 정확하고, 반올림은 앱이 쓴다(`price * rate // 10000`). 보이는 꼴은
+ `{cents:.2d}`: i64를 소수점 아래 두 자리로 나눠 쓴다(1234 → `12.34`, −5 → `-0.05`). JSON의 경계는 i64를 정수로 쓴다.
+ - **교체.** number, bool, i64는 정확할 때만 서로 옮긴다(`pure_cell_as`: 정수인 number ↔ i64, 0·1 ↔ bool). 아니면 기본값이다.
+ - 걸음: 5a(`//`와 `/`의 규칙), 5b(i64 접기의 정확한 합), 5c(`.Nd`와 TPC-C의 돈을 i64 센트로, SQLite도), 5d(교체의 규칙과 008).
+ - **5a 만듦(2026-10-19).**
+ - Pure: 명령 FLOORDIV(95, 명령 96개). number의 내림한 몫을 파이썬의 float `//`처럼 정확하게 낸다(나머지를 뺀 a를 b로 나누고
+ 가까운 정수로, 0의 부호는 a / b의 것, 0으로 나누면 `divide`). 새 명령이라 JIT, 계층, 묶음 실행기의 빠른 길은 그것을 모르고
+ 실행기로 넘긴다(DIV의 인자로 했다면 그 길마다 고쳐야 했다).
+ - aup: `//`를 `/`와 같은 우선순위로 더했다(number는 FLOORDIV, i64는 I64_DIV). i64끼리의 `/`는 거절한다("an i64 divides by //").
+ i64의 `/`를 쓰던 시험 셋(받아들인 꼴 하나, i64의 시험 앱, 무작위 프로그램의 i64 식)을 `//`로 고쳤다.
+ - 시험: 단위 시험 `floor_division`(7 // 2, −7 // 2, 7 // −2, 1 // 0.1 = 9, 0 // −3 = −0, 1e300 // 7, 0으로 나누기). aup의 시험이 무작위
+ 200쌍의 `a // b`와 `a % b`를 파이썬과 비트까지(−0의 부호까지) 견준다. 진단 하나(305).
+ - 명령 수(b43 대 b42): 실행기만의 BFS −0.09%, 나머지 ±0.001% 안이다. 은행 질의(s42와 s43을 한 번에 번갈아 여섯 번)는 −0.20%에서
+ 0.00% 사이다.
**순서의 까닭.**
- 1과 2가 묶음의 명세 대부분을 연다. 가장 값이 크다.