Skip to main content

List

A List expression is a vertical list of items, where each item is an expression.

Semantics​

  • Returns a FEEL List: [item1, item2, item3].
  • Useful for defining fixed collections of data to iteration over.

Example​

List
1
2
3

Result: [1, 2, 3]

FAQ​

Can items in a boxed List be of different types?

Yes — FEEL lists are heterogeneous, so a boxed List can mix numbers, strings, booleans, contexts, even other lists. That said, lists tend to be more useful when items share a type, because most operations you'd want to do (filter, sort, sum, aggregate) need consistent types. If your items are structured records that share the same fields, prefer a Relation — it makes the column layout explicit. If they're truly heterogeneous, a Context with named entries is usually clearer.

Can a boxed List be empty?

Yes — an empty List evaluates to the empty FEEL list []. Most FEEL built-ins handle empty lists cleanly: count([]) returns 0, sum([]) returns 0, list filters on an empty list return another empty list. The cases to watch are operations that expect at least one element — min([]) and max([]) return null, and any downstream consumer that depends on a specific element (list[1] for the first item, for example) will see null instead of failing loudly.

How is a boxed List different from a FEEL list literal like `[1, 2, 3]`?

Semantically they're identical — both evaluate to the same FEEL list value. The difference is presentation. A boxed List makes each element a separate row in the modeler, which is easier to edit and review when the list has many items or each item is itself a complex expression. A FEEL list literal lives inside a single Literal Expression cell, which is more compact for short lists of simple values. Use a boxed List when items are non-trivial, use a literal when the list is short and trivially readable as [a, b, c].