Gooo 선언 안에 본문 조립 의도 적기

2026-10-06: 서로 다른 타입의 본문 구멍 채우기

PR #1267에서 source_fill의 각 구멍이 자신의 후보 문법을 선언할 수 있게 했습니다. 조건과 정수 반환값처럼 서로 다른 타입의 표현을 함께 조립할 수 있습니다.

derive assignments max_candidates "16" {
    hole "condition" grammar "integer-predicate/v1" max_expressions "8"
    hole "yes" grammar "integer-offset-constant/v1" max_expressions "2"
}

integer-predicate/v1은 true, false와 훈련 입력값에 대한 비교 후보를 만듭니다. integer-offset-constant/v1은 입력값 주변의 정수 표현식을 만듭니다. 컴파일러는 후보를 모두 연결한 뒤 타입과 선언된 사례를 확인합니다. 모델은 이 완성 후보에서 선택하고, 모델이 연결되지 않으면 결정론적 선택이 유지됩니다.

재현 가능한 조건부 예제는 세 선언 사례를 모두 맞췄습니다. 조건 문법 후보는 일부만 열거했으므로 완전성 영수증은 문법 범위를 PROGRESS로 기록합니다. 이는 전체 정수 범위에 대한 보증이 아닙니다. 문법·지표·한계는 컴파일러 문서에, 언어의 더 넓은 방향은 연구 및 다음 단계에 있습니다.

PR #1267은 필수 여섯 CI 체크 후 dev에 병합됐고, 정확한 트리 스냅샷 PR #1268로 main에 반영됐습니다. 이 조립 경로의 이번 예제 실행은 결정론적이었고, 실제 Laya 응답 시간은 측정하지 않았습니다.

생성 결과를 다음 개발에 다시 쓰기

개발 #1217을 CI와 독립 증거 확인 후 병합했습니다. main #1218이 같은 코드를 배포한 PR입니다. main f62eb5f0로 CLI·실행기를 함께 설치했고 CI37190298986의 필수 여섯 검사·전체 실행과 독립 증거가 모두 PASS였습니다. 생성한 Gooo 본문을 다시 사용할 수 있는 체크포인트를 추가했습니다. 이전에는 선택된 본문을 원본에 넣으면 지역값의 대안 이름과 위치가 어긋나 다음 생성이 실패할 수 있었습니다. 이제 시작 본문 baseline, 선택한 경로 picked, 현재 실행할 본문 computes를 함께 보관합니다. 기준 지도와 그 지도에서 고른 경로를 완성한 작업물 옆에 놓는 방식입니다.

gooo body-codegen --json --activity Qualified \
  examples/body-codegen/source-assembly.gooo.fixture > /tmp/generation.json
gooo body-realize --source examples/body-codegen/source-assembly.gooo.fixture \
  --generation /tmp/generation.json --out /tmp/gooo-realized
gooo body-codegen --json --activity Qualified /tmp/gooo-realized/realized.gooo

생성 JSON의 gooo_source는 선택된 활동을 반영한 Gooo 파일입니다. body-realize는 선택·생성 코드·유한 실행 관측을 재구성한 뒤 원본과 기록, realized.gooo, realization.json을 새 폴더에 저장합니다. 모델을 추가로 호출하지 않으며 낮은 완전성도 그대로 기록합니다. baseline과 picked는 구문·의미 중간 표현·양방향 변환에 함께 남습니다. 새 본문으로 계획을 바꾸려면 기존 두 필드를 지우고 현재 computes를 기준으로 선택 위치와 예시를 맞춥니다.

실제 자체 모델을 쓴 두 과제 × 모델/결정론 × 세 번의 연속 생성에서 12회 생성, 선택 48/48, 별도 실행 108/108, 실제 실행 24회를 확인했습니다. 각 경로는 저장 후 두 번 다시 생성해도 Gooo·Go·계획 지문이 유지됐습니다. 모델 생성은 총 여섯 번 추론했고 열두 번 저장 과정의 추론은 0번입니다. 기존 가중치를 사용했으며 새 학습과 Laya 호출은 없었습니다.

모델 경로의 생성 중앙값은 두 과제에서 15.696ms·13.214ms, 저장은 15.738ms·13.984ms였습니다. 각각 새 명령을 시작하고 모델/자료를 읽는 비용을 포함합니다. 실제 빌드와 두 번 실행의 중앙값은 319.398ms·310.140ms였습니다. 세 관측씩 고정 순서로 진행했고 빌드 캐시가 있어 속도 개선 판단에는 부족합니다. 모델 자체 추론은 19.75–32.88µs, 생성 과정 최대 RSS는 20.0–21.02MiB였습니다. 시스템 전체 CPU 증가량은 관측하지 않았습니다.

원본·재현 도구·시간과 메모리에 실패한 첫 후보도 남겼습니다. 두 과제를 반복하고 제어 조건을 둔 수치입니다. 현재 기능은 주어진 유한 선택지의 재사용을 확인하며, 더 넓은 본문·의도와 타입으로 확장하는 작업이 이어집니다.

설치된 main f62eb5f0에서도 같은 열두 번의 생성·저장·다음 생성과 실제 실행을 다시 확인했습니다. 선택 48/48·별도 실행 108/108, 실제 모델 판단 여섯 번과 저장 과정 판단 0번이었으며 앞선 관측의 Gooo·Go·계획·모델 입력 지문과 같았습니다. 체크포인트를 입력으로 받은 병렬 실행기도 작업자 두 개로 모델/결정론 요청 여덟 개를 처리했고 실행 기대값 72/72와 정상 EOF 종료를 확인했습니다. 이 관측에서 교착은 나타나지 않았습니다.

2026-10-04. 본문과 조립 규칙을 함께 작성하는 assembling을 추가했습니다. Gooo의 구문, 의미 중간 표현, 양방향 변환과 실행 명령이 이 선언을 보존합니다.

개발 #1215·main #1216를 각 CI·독립 증거 확인 후 병합했습니다. main 8a08adbb에서 CLI와 별도 실행기를 Go1.27.1·SDK21로 함께 설치했습니다. 새 설치의 CLI 여덟 요청과 병렬 실행기 여덟 요청은 제공한 실행 기대값 144/144, 실제 실행 32회와 정상 EOF 종료를 확인했습니다.

설계도 옆에 작은 조립 메모와 측정표를 붙이는 방식입니다. computes가 시작할 본문을 담고, choice가 바꿔 볼 부분, intent가 한영 지시, case가 확인할 입출력, attempts가 살펴볼 후보 수를 담습니다.

작은 선언 읽기

package offsets
namespace offsets
entity Integer id "offsets://integer"
activity Offset(Integer) -> Integer computes "return input - 2" assembling {
    choice "offset-order" operand_order at "0" intent "2에서 입력을 뺀다. Subtract input from two."
    case "-1" -> "3"
    case "4" -> "-2"
    attempts "2"
}

여기서는 첫 뺄셈의 피연산자 순서를 바꿀 수 있습니다. 시작 본문은 input-2이고, 선언한 두 예시를 충족하는 본문은 2-input입니다. 컴파일러가 두 후보를 타입이 정해진 구조로 구성하고 예시 결과를 비교합니다. 모델을 연결하면 그 순서를 제안하며, 생략하면 정해진 순서로 후보를 살펴봅니다.

이 파일을 offset.gooo로 저장하고 다음 명령으로 생성 결과를 읽습니다.

gooo body-codegen --json --activity Offset offset.gooo
gooo body-context --include-plan --activity Offset offset.gooo

저장소 예제를 곧바로 실행하기

컴파일러 저장소 루트에서 아래 명령을 실행합니다. 이미 설치된 Go1.27.1을 찾아 생성한 코드를 빌드하고, 별도 기대값의 실제 출력을 두 번 확인합니다.

gooo body-path-run \
  --source examples/body-codegen/source-assembly.gooo.fixture \
  --activity Clamp \
  --cases examples/body-codegen/source-assembly-clamp-cases.json \
  --repeat 2 --timing --out clamp-results

gooo body-path-run --verify-timing --out clamp-results

--out은 새 폴더를 사용합니다. 원본, 생성 Go, 선택 결과, 실제 실행과 시간 기록을 저장합니다. 같은 본문을 다시 만들면 보관한 실행파일을 재사용하며 현재 입력의 실행은 다시 관측합니다. Clamp는 음수를 0, 0부터 10까지를 입력값, 10보다 큰 값을 10으로 만드는 범위 조립 예제입니다.

body-codegen에는 --path-model /path/to/model.json, 파일 실행에는 --model /path/to/model.json을 추가합니다. 이번 관측은 공개 연구 저장소의 models/own-three-feedback-v1/set-feedback/models/fp32/model.json을 사용했습니다. 모델의 지원 선택 수와 입력 예산을 확인해야 합니다.

별도 실행기 요청도 같은 선언을 사용합니다. 해당 활동에 assembling이 있으면 스트림의 document를 생략하고 execution_cases에 별도 실행 기대값을 줍니다. 생성 후 곧바로 실행하는 기존 --execute와 병렬 작업자 경로를 유지했습니다.

어디를 선택할 수 있나

선택 종류	바꿔 볼 부분
operand_order	이항 연산의 피연산자 순서
local_reference	읽는 지역값, alternative에 대안 이름 지정
assignment_target	대입하는 지역값, alternative에 대안 이름 지정
branch_layout	조건의 분기 구성
root_order	인접한 두 본문 문장의 순서

at은 해당 종류가 나타나는 위치를 0부터 센 값입니다. 본문 편집으로 위치가 움직일 수 있으므로 의도와 예시를 함께 수정합니다. 지역 정수·불리언, 조건식, 대입, 중첩 분기와 else if를 현재 Integer→Integer 본문에서 사용합니다. 소스는 최대 128KiB, 표현식과 문장은 각각 128칸, 중첩 깊이는 16입니다. 선택지 1–16개, 사례 1–128개, 탐색 후보 1–64개를 선언할 수 있습니다.

활동 안의 조립 선언이 전체 계획을 정합니다. 외부 --path-plan이나 스트림 document를 함께 주면 충돌을 표시합니다. 선언이 없는 활동에서는 기존 외부 레시피도 계속 사용할 수 있습니다.

이번 관측과 다음 개선

두 과제에서 선언 방식·외부 계획 방식, 자체 모델·결정론을 네 번씩 실행했습니다. 같은 변경 트리의 후보 0f7ec4c0, macOS arm64·Go1.27.1에서 관측했습니다. 32회 생성에서 선택 사례는 128/128, 별도 실행 사례는 288/288이었습니다. 같은 과제·모드의 모델 입력과 생성 Go는 두 작성 방식에서 일치했습니다.

과제	모델 첫 후보	모델 검사 후보	결정론 첫 후보	결정론 검사 후보
지역값·조건 조립	0/5	3	1/5	2
범위 분기 조립	1/3	4	3/3	1

이번 두 과제에서는 모델의 첫 선택이 더 약했습니다. 유한 TDD 탐색이 다음 후보를 검사해 제공한 예시를 충족했습니다. 그 실패와 추가 시도 비용을 다음 모델 개선의 자료로 보존합니다. 전체 자연어 이해나 모든 입력의 정답률은 별도로 측정해야 합니다.

선언 방식의 모델 연결 반복 응답 중앙값은 약 27–29ms, 공동 모델 판단은 약 20µs였습니다. 첫 요청은 빌드를 포함했고, 반복 요청은 실행파일을 재사용했습니다. 선언 확인의 비용도 증가했습니다. 전체 명령의 CPU 시간/벽 시간은 한 코어 기준 62.1–81.0%, 최대 RSS는 82.48–83.48MiB였습니다. 컴파일·실행을 포함하는 값이며 모델 텐서는 74,624바이트입니다. 컴퓨터 전체 CPU 증가량은 관측하지 않았습니다.

가중치를 그대로 사용했고 새 학습은 하지 않았습니다. 다음 단계는 낮은 순위의 실패 예시를 구분하고, 같은 후보 예산에서 부분 충족과 회귀를 비교하는 것입니다.

위 비교 실험과 별도로, 새 설치본의 모델 재사용 응답은 지역값 예제 34.745ms, 범위 예제 33.816ms였습니다. 각 수치는 반복 요청 한 건의 관측입니다. 첫 요청은 각각 497.687·532.473ms로 빌드를 포함했습니다. 설치 버전과 검사 근거.

별도 후속 실험에서는 첫 후보의 0/5 실패와 실제 개발 CI의 PASS 상태를 다시 모델 문맥에 넣었습니다. 두 요청이 각각 공동 판단 두 번·후보 두 개를 검사해 선택 5/5와 별도 실행 11/11을 얻었습니다. CI 상태의 효과는 별도로 비교하지 않았습니다. 처음 다른 예제의 기대값을 섞어 얻은 두 요청의 1/11도 같은 부록에 보존했습니다. 이 후속 실험은 위 32회 집계와 구분합니다. 후속 문맥과 입력 실수의 원본.

문법·범위 · 모든 관측과 재현 · 모델 카드