Appendix — Tuples and Indexed Paths

Appendix to: AEON Specification v1 Status: informative summary for consolidated v1

Canonical topic owners: ../value-types-v1.md, ../structure-syntax-v1.md, ../addressing-references-v1.md

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.

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<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

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

Examples:

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:

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[])`

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:

Reference = "~" Path	"~>" Path ;
Path = Root? Segment+	Root ;
Segment = MemberSegment	IndexSegment	AttrSegment ;

Example:

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 / 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

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 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

specs/04-official/v1/AEON-spec-v1.md (tuple/index path grammar and conformance)
specs/04-official/v1/AEOS-spec-v1.md (validator-facing tuple/index constraints)
specs/04-official/v1/appendices/appendix-aes.md (event model implications for tuple/list)
specs/04-official/v1/appendices/appendix-addressing.md (indexed canonical path rendering)