Lua 언어 지원
상태: 구현 중 — 리더·C 모듈·생성기·게이트·업데이터·문서까지 됐고, 남은 것은 마무리 절차입니다(14절). 결정 9개는 13절이고, 구현하면서 갈라진 곳 3개도 거기 있습니다
새 코드 생성 타깃입니다. 형식은 바뀌지 않습니다 — v106을 읽는 리더가 하나 더 생기는 일이고, 변환기·익스포터·기존 언어는 손대지 않습니다. Swift와 같은 종류의 작업이고, 문서의 형태도 그쪽을 따릅니다.
이 언어에는 다른 14개에 없던 전제가 하나 있습니다 — 암호화·해시·체크섬 계산은 C로
구현해서 속도 문제가 없어야 합니다. 이 전제는 새 방침이 아니라
v104가 적어 둔 기준의
적용입니 다: 「그 언어에서 바이트 단위 루프가 수 MB를 감당하는가」— Lua는 감당하지 못하는
쪽이고, Python이 cryptography 패키지로 간 것과 같은 갈림에서 Lua의 「플랫폼」은
C입니다. 그래서 이 문서가 정하는 것의 절반이 그 C 모듈의 형태입니다.
1. 범위 — 바뀌지 않는 것을 먼저
| 무엇 | 상태 |
|---|---|
| 와이어 형식(v106)·변환기·익스포터 | 무변경. 리더를 하나 더 쓰는 일입니다 |
| 코어의 등록 코드 | 없습니다. [TabbitTarget("lua", ...)] 어트리뷰트 스캔이므로 CLI·recipe 스키마·레지스트리에 이름이 들어가지 않습니다 |
| 골든 트리 | 무변경. 시나리오별 골든은 binary·csharp·typescript·html·json 다섯 개뿐입니다 |
| 기존 언어 | 무변경 |
| 샘플 산출물 | 무변경. 샘플 recipe에 이 타깃을 넣지 않는 한 |
새로 생기는 것은 런타임 3개(리더·업데이터·네이티브 C 모듈), 생성기 둘(생성기·뷰), 템플릿 다섯, 프로파일 하나, 게이트 아홉, 하네스용 벤더 툴체인 하나, 문서 하나입니다. 런타임이 둘이 아니라 3개인 것이 이 언어의 다른 점입니다.
이 문서의 나머지
| 무엇 | 어디 |
|---|---|
| 결정 아홉 | 두 모드 · C 모듈 · 디코드 · 행의 형태 · 이름 · uuid · 산출물 · HTTP |
| 타입 매핑과 게이트 | 타입이 Lua 에서 무엇이 되는지, 그리고 하네스가 Lua 를 만드는 이유 |
| 승인 · 단계 · 문서 | 승인 대기 항목, 구현 단계, 그리고 문서에 적을 것 |