Chuchu arrays are deliberately small and predictable. They have a fixed size, one element type and checked bounds. There is no resizing, no sparse storage and no mixed-type list hiding behind the same syntax.
set a to [1, 2, 3]
set b to [4, 5, 6]
set result to a * b
show sum(result)
show len(result)Fixed size, checked access
An array holds between 1 and 256 elements, and its length is known at compile time. Indexing is checked at runtime: an index outside the array stops the program with a clear error rather than reading whatever happens to be next in memory. Elements cannot be assigned one by one yet, so an array is built once and then read or transformed as a whole.
Element-wise arithmetic
Arithmetic between two arrays of the same length applies element by element. The result has the same length and element type. sum reduces an array in its original order, and floating-point reductions keep that order instead of silently reassociating the values.
Checked evaluation order is part of the language, not an optimisation detail. Reordering a reduction can change which overflow happens first.
Why keep it small
A small array model makes the semantics easy to state and easy to test: no hidden allocations, no capacity growth and no aliasing surprises. It is enough for the numerical workloads Chuchu targets today, and it leaves room to add a richer collection type later without changing what these arrays mean.
The language reference lists the array rules and the runtime checks in full. The numerical example is a good place to start if you want to compile one yourself.