Lexical Structure & Layout

Consult this page when a .tpz file appears syntactically valid line by line, but item boundaries or identifier and literal spellings remain uncertain. Topaz accepts Unicode names and evaluates completed lines as finished statements. Parentheses, brackets, and continuation tokens permit expressions to span multiple lines without an explicit line-continuation character.

Start with a complete source file

Save this as lexical-layout.tpz:

let ready = true
let archived = false
let missing = null
let 상태 = "ready"

let total =
    40 +
    2

print("{상태}: {ready}, {archived}, {missing}, {total}")

Check and run it:

topaz check lexical-layout.tpz
topaz run lexical-layout.tpz

The output is:

ready: true, false, null, 42

Across these five bindings, the program demonstrates four literal categories: boolean values true and false, the absence value null, a string, and decimal numbers. 상태 functions as a standard identifier. Keywords such as let, true, false, and null retain their English spellings, whereas custom identifiers can incorporate Unicode letters, underscores, trailing digits, and emoji.

Read the line breaks from what the parser can see

The first four bindings each complete on a single line, allowing each newline to separate distinct top-level items. The total expression continues because = and + appear at line endings. A trailing operator signals to the parser that another operand follows.

Within parentheses, brackets, record braces, parameter lists, and other delimited constructs, newlines function as whitespace rather than item separators. Blocks, match bodies, and concurrent bodies follow different rules. Because their contents consist of statement lists, a completed line can conclude an item. Wrap complex expressions in parentheses to resolve potential ambiguity rather than relying on indentation. Indentation aids readability, whereas delimiter and continuation rules govern structural parsing.

Semicolons serve as valid statement separators where statements are permitted, though standard Topaz code omits them. A newline preceding else remains part of the surrounding if or timed concurrent expression.

Names, comments, and strings

An identifier begins with a Unicode letter, _, or emoji, followed by optional Unicode digits. The standalone _ is reserved. It functions as a pattern wildcard and a pipeline argument placeholder rather than a readable value or bindable name. Identifiers such as _internal operate as standard names.

Use // for line comments and /* ... */ for block comments. Block comments do not nest. Integer and floating-point literals use decimal notation. Alternate numeric bases and underscore digit separators are not canonical.

Double-quoted strings support escape sequences such as \n alongside {expression} interpolation. Triple-quoted strings provide multiline formatting. Their closing delimiter sets the exact space-and-tab prefix removed from nonblank lines. Topaz preserves Unicode scalar sequences without implicit normalization.

Common correction

Do not place a binary operator at the start of a statement line when it could be parsed as a unary + or -. Keep + or - at the end of the preceding line, or enclose the entire expression in parentheses. Avoid using s[i], s.length, or slice syntax for text manipulation. Inspect strings using s.scalars(). The Strings & Templates page details this design approach.

Token recognition follows the longest valid match rule. Consequently, ..., .., ..<, ?., and postfix ? remain distinct. Single-quoted strings, character literals, nested block comments, string slicing, grapheme-cluster APIs, and implicit Unicode normalization are excluded from the current surface.

Consult Operators & Expressions for value-producing expressions and Types for annotations and inference. Refer to Forbidden & Deferred Forms when a familiar syntax pattern is rejected.