토파즈는 프로그램을 검토하기에 충분히 읽기 쉽고 실행하기에 충분히 명확한 실행 가능한 의도 선언으로 봅니다. 목표는 문법을 늘리는 것이 아니라 일반적인 프로그램을 직관적이고 일관되게 만드는 것입니다.
하나의 의도, 하나의 표기
일반 코드에서는 동일한 의도를 표현하는 구문을 중복하여 제공하지 않습니다. 복구 가능한 실패는 Result, 값 부재는 Option이나 null을 포함한 타입, 리소스 해제는 defer, 조건별 구조 분해는 match로 표현합니다. 다른 언어에서 익숙한 약식 표기를 무분별하게 도입하지 않는 이유도 이와 같습니다.
언어가 의미를 정한다
인터프리터는 프로그램의 기준 실행 경로입니다. 그러나 인터프리터의 내부 구현이 언어의 명세를 결정하지는 않습니다. 현재 SPEC이 관찰 가능한 값, 오류, 평가 순서, 리소스 해제 규칙을 정의하며, 구현체는 해당 규칙을 준수합니다.
여러 백엔드는 검증 수단이다
Rust와 Python 타깃은 동일한 프로그램을 서로 다른 방식으로 실행합니다. 두 경로 모두 인터프리터와 동일한 결과를 도출해야 합니다. 이로 인해 코드상의 실수나 모호한 규칙이 명확히 드러납니다. 타깃에서 지원하지 않는 형태는 임의로 의미를 바꾸어 실행하지 않고 컴파일 단계에서 거부합니다.
작은 문법, 깊은 규칙
문법이 간결하다고 해서 단순하다는 뜻은 아닙니다. 표기 체계는 최소화하되, 평가 순서, 타입, 실패 처리, 순회, 리소스 수명처럼 프로그램 동작에 영향을 주는 요소는 정교하게 정의합니다. 이러한 제약 덕분에 개발자와 코드 생성 도구가 동일한 규칙을 적용하기 용이합니다.
실제 프로그램이 다음 기능을 정한다
표준 라이브러리와 런타임은 단순 예제를 채우기 위해 확장하지 않습니다. 실제 운용 및 유지보수되는 애플리케이션에서 문자열, 숫자, 컬렉션, 파일, 패키지, 진단 기능의 한계가 드러날 때 비로소 확장합니다. Lispex-in-Topaz의 약어인 LIT와 리스펙스의 제한된 통합 역시 재귀, 이식 가능한 값, 상태, 출력 및 오류 처리를 함께 검증하는 용도로 활용됩니다. 이러한 실전 검증 사례는 개발 우선순위를 결정하는 근거로 삼으며, 일회성 문법을 추가하는 명분으로 사용하지 않습니다.
공개 상태
문서에서는 현재 정식 버전에서 제공하는 기능과 향후 계획을 명확히 구분하여 기술합니다. 제한 사항은 해당 페이지에서 상세히 설명합니다. 다만 내부 개발 절차를 언어 규칙처럼 드러내지는 않습니다.