Values & types

Ecko is dynamically typed. type_of(v) names a value's type:

Functions are values too (fn, native_function).

Truthiness

false and null are falsy. So are 0, "", [], {} and b"" - the empty value of each type.

No implicit conversion between kinds

"count: " + 5          # error
"count: {5}"           # interpolate instead
string(5) + " items"   # or convert explicitly

Ecko does not concatenate a number onto a string for you. The same stance applies to bytes (bytes + string is an error) and secrets ("x" + secret is an error): where two kinds of thing meet, the source says which way the conversion goes.

Numbers do mix, with one hard rule: int and decimal mix and give decimal, int and float mix and give float, and decimal with float is an error - a binary float must never silently contaminate an exact value. See Numbers.

Conversions

int("42")        float("3.5")     string(99)
bool(1)          decimal("0.1")   bytes("hi")
list(b"\x01")    json_encode(v)   json_decode(s)

int("abc") raises rather than returning 0 or null - a failed conversion is a failure, not a default.

Collections are values

Binding a collection to a new name gives an independent value; there is no aliasing to reason about. Copy-on-write underneath makes that cheap. See Assignment through fields & indexes.

The single deliberate exception is cell.

Access is strict

xs[9] and m.missing raise. get(xs, 9) and get(m, "missing") return null. See Structured data access - the distinction is a load-bearing part of the error dialect.

Determinism

Maps are unordered internally but print and JSON-encode with sorted keys, and map iteration yields pairs in sorted key order. So output is reproducible without you sorting anything, which is what lets the test suite assert on it.