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