토파즈는 프로그램을 실행할 수 있는 의도로 봅니다. 사람이 읽기 쉽고, 도구가 검사할 수 있고, 여러 실행 방식으로 옮겨도 의미가 달라지지 않을 만큼 정확해야 합니다.
하나의 의도, 하나의 표기
일반 코드에는 같은 의도를 표현하는 방법을 여러 개 두지 않습니다. 복구 가능한 실패는 Result, 값 없음은 Option이나 null을 포함한 타입, 자원 정리는 defer, 조건부 구조 분해는 match로 표현합니다. 다른 언어에서 익숙한 약식을 임의로 받아들이지 않는 이유도 같습니다.
언어가 의미를 정한다
해석기는 프로그램의 기준 실행 경로입니다. 그러나 해석기의 내부 구현이 언어를 정하는 것은 아닙니다. 현재 SPEC이 사용자가 볼 수 있는 값, 오류, 평가 순서, 자원 정리 규칙을 정하고 구현은 그 규칙을 따릅니다.
여러 백엔드는 검증 수단이다
Rust와 Python 백엔드는 같은 프로그램을 다른 방식으로 구현합니다. 두 경로가 해석기와 같은 결과를 내야 하기 때문에 실수나 애매한 규칙이 더 잘 드러납니다. 백엔드가 지원할 수 없는 형태는 다른 뜻으로 실행하지 않고 컴파일 단계에서 거부합니다.
작은 문법, 깊은 규칙
문법이 작다는 말은 단순하다는 뜻이 아닙니다. 표기는 적지만 평가 순서, 타입, 실패, 순회, 자원 수명처럼 프로그램 결과에 영향을 주는 부분은 자세히 정합니다. 이런 제약 덕분에 사람과 코드 생성 도구가 같은 규칙을 사용하기 쉽습니다.
실제 프로그램이 다음 기능을 정한다
표준 라이브러리와 런타임은 예제를 채우기 위해 늘리지 않습니다. 유지보수 애플리케이션이 문자열, 숫자, 컬렉션, 파일, 패키지, 진단의 부족한 점을 드러낼 때 확장합니다. 제한된 LIT·Lispex 통합도 재귀 값, 상태, 출력과 오류 처리를 함께 시험합니다. 이런 제품 증거는 우선순위를 정하는 데 쓰되 일회성 문법을 추가하는 구실로 삼지 않습니다.
공개 상태
문서는 현재 정식 버전에서 사용할 수 있는 기능과 앞으로의 계획을 구분합니다. 제한 사항은 필요한 페이지에서 설명하되 내부 개발 절차를 언어 규칙처럼 노출하지 않습니다.