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.
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<T> | Homogeneous-element intent |
(...) | TupleLiteral | tuple<T1..TN> | Positional/arity intent |
AEON uses "list" and "tuple" terminology, not "array".
3. Grammar Surface
3.1 Value Production
Grammar productions: 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 aTupleLiteralThere is no grouping-parentheses syntax in AEON Core
An empty
()is an empty tuple
3.3 Generic Type Annotation
Grammar productions: TypeAnnotation ::= ":" TypeRef Clarifier?; TypeRef ::= TypeIdent GenericArgs? ( "." TypeIdent GenericArgs? )*; GenericArgs ::= "<" Ws? TypeRef ( Ws? "," Ws? TypeRef )* Ws? ">".
Examples:
items:list<string> = ["a", "b"]
point:tuple<int32,int32> = (10, 20)
score:tuple<string,int32> = ("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 |
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 elementIndex 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
0Malformed 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[]) |
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:
Grammar productions: Reference ::= "~" Path | "~>" Path; Path ::= Root? Segment+ | Root; Segment ::= MemberSegment | IndexSegment | AttrSegment.
Example:
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<T>
Exactly one type argument
Indicates homogeneous-element intent
Example:
list<string>,list<int32>
tuple<T1..TN>
One or more type arguments
Indicates positional/arity intent
Example:
tuple<string,int32>,tuple<int32,int32,float64>
Core Parsing Role
AEON Core:
Parses these forms syntactically
Preserves
ListNode/TupleLiteralshape 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 |
Type hint annotations (:tuple<string,int32>) 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 validGeneric
<...>type arguments are validIndexed 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:
TupleLiteralvalue kind, element sub-eventsDiagnostics:
invalid_index_format, generic arity mismatchValidator/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)