# Appendix — Tuples and Indexed Paths **Appendix to:** AEON Specification v1 Canonical topic owners: AEON Core v1 Value Types Reference, AEON Core v1 Structure and Syntax Reference, and AEON v1 Addressing, SANSA Literals, and References Reference. If this appendix conflicts with the canonical v1 references, the canonical v1 references win. This appendix defines the tuple/list structural distinction, grammar surface, indexed canonical paths, AES emission, and the Core-versus-validation authority boundary. > [!WARNING] > **Gating:** Features in this appendix are part of the consolidated v1 language line unless explicitly profile-gated. ## 1. Design Goals This chapter: - Separates list and tuple shapes in syntax and AES value kinds - Uses indexed canonical paths for positional addressing - Keeps validation authority outside AEON Core - Preserves deterministic parse/print/resolution behavior ## 2. Terminology | Surface Syntax | AES/AST Value Kind | Type Constructor | Semantics | | :--- | :--- | :--- | :--- | | `[...]` | `ListNode` | `list` | Homogeneous-element intent | | `(...)` | `TupleLiteral` | `tuple` | Positional/arity intent | *AEON sequence terminology* AEON uses "list" and "tuple" terminology, not "array". ## 3. Grammar Surface ### 3.1 Value Production ```ebnf Value ::= Literal | Reference | Object | List | Tuple TypedValue ::= TypeAnnotation "=" Value List ::= AttributeList? "[" ListBody? "]" Tuple ::= AttributeList? "(" TupleBody? ")" ListBody ::= ( (Value | TypedValue) ListSeparator? )* TupleBody ::= ( (Value | TypedValue) ListSeparator? )* ListSeparator ::= "," | Newline ``` ### 3.2 `()` Interpretation - `()` is always a `TupleLiteral` - There is no grouping-parentheses syntax in AEON Core - An empty `()` is an empty tuple ### 3.3 Generic Type Annotation ```ebnf TypeAnnotation ::= ":" TypeRef Clarifier? TypeRef ::= TypeIdent GenericArgs? ( "." TypeIdent GenericArgs? )* GenericArgs ::= "<" Ws? TypeRef ( Ws? "," Ws? TypeRef )* Ws? ">" ``` Examples: ```aeon items:list = ["a", "b"] point:tuple = (10, 20) score:tuple = ("alice", 95) values:list = [:int32 = 3, :string = "4"] pair:tuple = (:float64 = 10.5, :float64 = 2.0) ``` ## 4. `<` Disambiguation | Context | `<` Meaning | | :--- | :--- | | TypeContext (after `:`) | Begins `GenericArgs` | | ValueContext with `< Identifier "("` | Node introducer form | | Other ValueContext | Currently invalid | *Less-than token disambiguation* Whitespace is not semantically significant for this disambiguation. ## 5. Indexed Canonical Paths Tuples and lists use indexed segments in canonical paths: ``` $.a[0] // first element of a $.a[1][2] // third element of second element of a $.a[0].@.meta // attribute on first element ``` Index segment model aligns with the addressing appendix (`member / index` identity segments with attribute selectors in addressing expressions). Canonicalization constraints (same as addressing rules): - Zero-based - Decimal digits only - No sign prefix - No leading zeros unless index is `0` - Malformed index forms produce diagnostic `invalid_index_format` ## 6. AES Emission AEON Core emits distinct value kinds for the two sequence forms: | Source Form | Emitted Kind | | :--- | :--- | | `[...]` | `ListNode(elements[])` | | `(...)` | `TupleLiteral(elements[])` | *AEON sequence forms and AES emission* Spans and source-order determinism remain unchanged from the baseline AES model. Assignment Events for sequence elements: - Each element of a list/tuple is addressable via its indexed canonical path - Elements emit as nested Assignment Events under the container's path ## 7. Reference Behavior with Indexed Targets Reference grammar supports indexed segments in path references: ```ebnf Reference ::= "~" Path | "~>" Path Path ::= Root? Segment+ | Root Segment ::= MemberSegment | IndexSegment | AttrSegment ``` Example: ```aeon items = (10, 20, 30) second = ~items[1] // clone of second tuple element (value: 20) ``` Reference visibility and no-forward rules remain governed by the addressing model. ## 8. Type Constructor Intent ### `list` - Exactly one type argument - Indicates homogeneous-element intent - Example: `list`, `list` ### `tuple` - One or more type arguments - Indicates positional/arity intent - Example: `tuple`, `tuple` ### Core Parsing Role AEON Core: - Parses these forms syntactically - Preserves `ListNode` / `TupleLiteral` shape in AST/AES AEON Core does NOT enforce: - Tuple arity conformance - Per-position type conformance - List element homogeneity ## 9. Validation Authority Boundary Structural tuple validation belongs to schema/profile stages, not AEON Core. | Layer | Responsibility | | :--- | :--- | | AEON Core | Parse syntax, emit `ListNode`/`TupleLiteral`, assign indexed paths | | AEOS | Enforce arity via `LENGTH_EXACT` | | | enforce per-position types via indexed-path `TYPE_IS` | | Profile/Tonic | Semantic interpretation, materialization | *Tuple validation authority* Type hint annotations (`:tuple`) on a binding do NOT automatically enforce arity or per-position type constraints. Schema rules must explicitly declare them. ## 10. Compatibility and Gating Tuple/generic/indexed-path behavior is part of the consolidated v1 baseline. In v1: - `(...)` tuple syntax is valid - Generic `<...>` type arguments are valid - Indexed reference paths are valid ## 11. Implementation Touchpoints - Parser: tuple literal production, generic type surface - Path parser/printer: index segments - Reference resolver: indexed targets - AES emitter: `TupleLiteral` value kind, element sub-events - Diagnostics: `invalid_index_format`, generic arity mismatch - Validator/path matcher: indexed path matching - CTS fixtures: golden AES outputs for tuple/list inputs ## 12. Open Items - Finalize grammar production names and chapter-level EBNF style for publication - Confirm final diagnostics set for generic arity and index format errors - Decide if any ValueContext `<` forms beyond node syntax are needed later ## 13. Related v1 Sections - AEON Specification v1 (tuple/index path grammar and conformance) - AEOS Specification v1 (validator-facing tuple/index constraints) - Appendix — Assignment Event Stream (AES) (event model implications for tuple/list) - Appendix — Addressing (indexed canonical path rendering) --- ## Related documents - [AEON v1 Value Types Reference](./aeon-core-v1-value-types.md) - [AEON v1 Structure Syntax Reference](./aeon-core-v1-structure-syntax.md) - [AEON v1 Addressing, SANSA Literals, and References Reference](./aeon-core-v1-addressing-references.md) - [Appendix — Assignment Event Stream (AES)](./appendix-aes-v1.md) - [AEOS Specification v1](./aeos-v1.md)