Introduction

This book is a tutorial and reference for CEL: its tokens, literals, basic types, operators, and collections.

Every CEL source form is an expression: it produces a value or helps compose one. Identifiers, calls, operators, collections, control flow, casts, and closures all participate in the same expression language.

The tutorial chapters follow this order:

Lexical conventions explains tokens, whitespace, comments, identifiers, and punctuation.
Literals and types explains scalar, compound, and closure values.
Operators explains precedence, associativity, arithmetic, comparison, logical, bitwise, cast, and range operators.
Conditional expressions explains value-producing if expressions.
Collections explains tuples and homogeneous arrays.
Closures explains closure literals and parameter typing.
Standard library explains additional operations available when the evaluation environment installs the library.

The Reference Manual gathers the complete grammar, exact operator rules, type names, library operations, and edge cases in one place.

Lexical conventions

The lexer divides source characters into tokens. It uses Rust token trees and inherits many behaviors from the Rust lexical structure. For the full CEL expression grammar, see the Reference Manual.

Syntax

compound_token = "&&" | "||" | "==" | "!=" | "<=" | ">="
               | "<<" | ">>" | ".." | "..=" .
identifier = identifier_start { identifier_continue } .

Whitespace and compound tokens

Spaces, tabs, and line breaks separate tokens. They do not otherwise change the meaning of an expression.

x + 1
x+1
if flag {
    1
} else {
    2
}

Adjacent punctuation characters combine into single tokens: &&, ||, ==, !=, <=, >=, <<, >>, .., and ..=.

a&&b
x<=y
1..=5

Comments and trivia

Comments may appear between tokens wherever whitespace is allowed.

x /* midpoint */ + 1
if ready { 1 } // done
else { 0 }

Line comments use // .... Block comments use /* ... */.

Identifiers and reserved words

An identifier is a non-empty name made from Unicode identifier characters. The first character may be a Unicode letter or _; later characters may also include Unicode digits. CEL follows the Rust identifier rules for the spellings that its lexer accepts.

x
user_name
value2
π
_temporary

These words are reserved for fixed roles in CEL source and cannot name user-defined values:

if
else
as
true
false

true and false are boolean literals. if and else introduce conditional expressions. as introduces an explicit cast. This restriction applies to value references and closure parameters. Member labels, record field labels, and type names have separate namespaces; CEL does not apply the value-name restriction to them. Boolean tokens remain literals in every namespace.

Literal tokens

The lexer recognizes these literal token categories:

integer literals
floating-point literals
string literals
boolean literals
character literals
byte literals
byte-string literals
C-string literals

42
3.5
"hello"
true
'a'
b'A'
b"bytes"
c"header"

The grammar defines the unit value (); it is not a literal token.

Delimiters and punctuation

CEL uses three delimiter pairs:

( ) for grouping, unit, tuples, calls, and closure parameter types
[ ] for arrays
{ } for if branches

It uses these structural punctuation marks inside expressions:

, between tuple elements, array elements, and call arguments
: in typed closure parameters
. before an unsuffixed tuple index

(1, 2)
[0, 1, 2]
|x: i32| x + 1
point.0

Operators

Operator tokens carry arithmetic, comparison, logical, bitwise, cast, and range syntax.

+ - * / %
== != < <= > >=
! && ||
& | ^ << >>
as
.. ..=

The grammar determines where each operator may appear and how tightly it binds. See Reference Manual for the full expression grammar.

Literals and types

CEL source includes literal values for numbers, booleans, text, characters, and bytes. It also uses tuple, array, range, and closure syntax to build larger values from expressions. For the full grammar of these forms, see the Reference Manual.

Built-in scalar type names

These sixteen names are the built-in scalar type names used by as casts and typed closure parameters.

Category	Types
Signed integers	`i8`, `i16`, `i32`, `i64`, `i128`, `isize`
Unsigned integers	`u8`, `u16`, `u32`, `u64`, `u128`, `usize`
Floating-point numbers	`f32`, `f64`
Other scalars	`bool`, `String`

Character, byte-string, C-string, and unit values are also valid in expressions, but are not additional built-in scalar type names.

Syntax

literal = integer_literal
        | floating_point_literal
        | boolean_literal
        | string_literal
        | character_literal
        | byte_literal
        | byte_string_literal
        | c_string_literal .

Integer literals

An integer literal is a whole number optionally followed by one of the accepted integer suffixes.

Suffix	Resulting type
none	`i32`
`i8`	`i8`
`i16`	`i16`
`i32`	`i32`
`i64`	`i64`
`i128`	`i128`
`isize`	`isize`
`u8`	`u8`
`u16`	`u16`
`u32`	`u32`
`u64`	`u64`
`u128`	`u128`
`usize`	`usize`

Unary - combines with a numeric literal to form a negative numeric expression. The numeric token must fit its declared type before negation. For example, -128i8 reports an out-of-range literal because 128i8 does not fit. Write -127i8 - 1i8 to express i8’s minimum with checked arithmetic. The same rule applies to every signed width and to literal patterns.

0
42i8
42i64
42u16
42u128
42usize
-1i32

Floating-point literals

A floating-point literal uses decimal or exponent notation, optionally followed by a floating-point suffix.

Suffix	Resulting type
none	`f64`
`f64`	`f64`
`f32`	`f32`

3.5
1e3
0.25f64
6.022e23f32
-3.5

Boolean, string, character, byte, and unit values

Boolean literals are true and false. String literals produce String values. Character literals produce char values. Byte literals produce u8 values. Byte-string and C-string literals produce byte-oriented string values. Write the unit value as ().

true
false
"hello"
'a'
b'A'
b"bytes"
c"header"
()

A byte literal such as b'A' and an explicitly suffixed integer such as 65u8 both denote u8 values.

Compound values

CEL also builds compound values from ordinary expressions:

() is the unit value, (expr) is grouping, (expr,) is a 1-tuple, and (a, b, c) is a tuple.
Arrays are homogeneous bracketed lists. An unannotated array is non-empty; a type annotation such as []: [i32] supplies the element type for an empty array.
|| expr and |x: T| expr are closure values.
These forms can nest inside calls, tuples, arrays, conditionals, and one another wherever the grammar permits.
Array homogeneity compares complete recursive shapes, including every tuple field and callable parameter/result. []: [(i32, [f64])] and []: [Fn((i32,), [i32])] need no registration of those aggregate shapes.

(1,)
(1, 2, 3)
[0, 1, 2]
[0, 1]: [i32]
[]: [i32]
|x: i32| x + 1

Source () and the empty tuple type are one canonical type, witnessed by Nil and represented by CNil<()>. Bridge ordinary Rust () with the zero-element IntoCStackList / IntoRustTuple conversion. An explicitly registered opaque host Leaf<()> remains a distinct host identity.

#![allow(unused)]
fn main() {
/// Normalizes source unit to the zero-element list and bridges it to Rust unit.
#[test]
fn source_unit_is_an_empty_list() {
    use cel_parser::{CELParser, OpLookup};
    use cel_runtime::{CNil, IntoCStackList, IntoRustTuple, Nil};

    let body = CELParser::new(OpLookup::new()).parse_str("()").unwrap();
    let mut body = body.prepare::<Nil, Nil>().unwrap();
    let unit: CNil<()> = body.call(&().into_c_stack_list()).unwrap();
    let (): () = unit.into_rust_tuple();
}
}

Host-registered records

A host can register a named record schema and operations without changing CEL. Write Sample { value: 3.0 } to construct a record when the host supplies that schema. Field labels select schema fields rather than variables; values evaluate in written order. Supply every field exactly once. Empty schemas accept {}; non-empty field lists reject trailing commas. CEL reports unknown constructors, unknown/duplicate/missing fields, and mismatched field types.

Records use exact scalar types: 1 is i32, never implicitly f64; use 1.0 or an explicit supported cast for an f64 field. Constructor names occupy a separate namespace from values, so a value named Sample does not hide the constructor. The host must separately register any operation such as .value; a record schema does not automatically create accessors.

This embedding example registers a Rust value and accessor. Both bare and parenthesized member spellings return 3.0; calling that numeric result with (record.value)() fails.

#![allow(unused)]
fn main() {
/// Evaluates a host record and its direct accessor with exact field types.
#[test]
fn registered_record_and_member_example() {
    use cel_parser::{OperationSignature, RecordField, RecordSchema, ResolvedLeafType};
    use cel_runtime::ValueType;

    /// A host-defined value, not a built-in CEL type.
    #[derive(Clone, Debug, PartialEq)]
    struct Sample {
        value: f64,
    }
    let sample = ResolvedLeafType::new("Sample", ValueType::leaf::<Sample>());
    let scalar = ResolvedLeafType::new("f64", ValueType::leaf::<f64>());
    let mut lookup = OpLookup::new();
    lookup
        .register_record(RecordSchema {
            ty: sample.clone(),
            fields: vec![RecordField {
                name: "value",
                ty: scalar.clone().into(),
            }],
            emit: Box::new(|s, _, _, _| s.op1(|value: f64| Sample { value })),
        })
        .unwrap();
    lookup
        .register_operation(OperationSignature {
            name: "value",
            operands: vec![sample.into()],
            result: scalar.into(),
            emit: Box::new(|s, _| s.op1(|sample: Sample| sample.value)),
        })
        .unwrap();
    let mut parser = CELParser::new(lookup);
    for source in [
        "Sample { value: 3.0 }.value",
        "Sample { value: 3.0 }.value()",
    ] {
        assert_eq!(
            parser.parse_str(source).unwrap().call0::<f64>().unwrap(),
            3.0
        );
    }
    assert_eq!(
        parser
            .parse_str("if (Sample { value: 3.0 }.value) > 0.0 { 1 } else { 0 }")
            .unwrap()
            .call0::<i32>()
            .unwrap(),
        1
    );
    assert!(parser.parse_str("Sample { value: 1 }").is_err());
    assert!(parser.parse_str("(Sample { value: 3.0 }.value)()").is_err());
    assert!(
        parser
            .parse_str("Sample { value: 3.0 }.value = 4.0")
            .is_err()
    );
}
}

Range values

A range expression produces a range value from zero, one, or two numeric endpoints. CEL supports bounded, half-bounded, and unbounded forms:

a..b
a..=b
a..
..b
..=b
..

Endpoint-bearing ranges require homogeneous numeric endpoints. Each endpoint is a full expression, so operators inside either side are parsed before the range is formed. The Operators chapter defines precedence and the non-chaining rule for range expressions.

Operators

CEL operators combine existing expression values. Precedence and associativity determine how unparenthesized expressions group. For the full grammar, see the Reference Manual.

Concept

Unary, binary, cast, and postfix operators all participate in one expression grammar. Postfix calls, tuple indices, and named members bind most tightly. Range forms bind most loosely. Logical operators short-circuit, and comparison and range forms do not chain.

Syntax

expression = closure_expression | range_expression .
range_expression = ".." [ or_expression ]
                 | "..=" or_expression
                 | or_expression [ ".." [ or_expression ] | "..=" or_expression ] .
or_expression = and_expression { "||" and_expression } .
and_expression = comparison_expression { "&&" comparison_expression } .
comparison_expression = bitwise_or_expression
    [ ("==" | "!=" | "<" | ">" | "<=" | ">=") bitwise_or_expression ] .
bitwise_or_expression = bitwise_xor_expression { "|" bitwise_xor_expression } .
bitwise_xor_expression = bitwise_and_expression { "^" bitwise_and_expression } .
bitwise_and_expression = bitwise_shift_expression { "&" bitwise_shift_expression } .
bitwise_shift_expression = additive_expression { ("<<" | ">>") additive_expression } .
additive_expression = multiplicative_expression { ("+" | "-") multiplicative_expression } .
multiplicative_expression = cast_expression { ("*" | "/" | "%") cast_expression } .
cast_expression = unary_expression { "as" identifier } .
unary_expression = (("-" | "!") unary_expression) | postfix_expression .
postfix_expression = primary_expression { postfix_suffix } .
postfix_suffix = "(" [ argument_list ] ")" | "." (unsuffixed_integer | identifier) .
argument_list = expression { "," expression } .

Worked examples

10 + 20 * 5
"cel" + "-" + "lang"
ok && round_ties_even(3.5) > 3.0
1u64 << 3u32
1.5 as i32
1 + 2..3 * 4

Exact rules

Precedence runs from lowest to highest in this order:

range forms
||
&&
comparison operators
bitwise |
bitwise ^
bitwise &
shifts << and >>
additive + and -
multiplicative *, /, and %
casts with as
unary - and !
postfix calls, tuple indexing, and named members

Within one precedence level, binary operators associate to the left. Comparison expressions consume one comparison operator, and range forms do not chain.

A call is a postfix () form with zero or more comma-separated arguments.
receiver.name and receiver.name() both invoke a unary named operation, ignoring same-named value bindings. receiver.name(a, b) supplies the receiver first, then explicit arguments; each evaluates once in source order. The member label is not a variable reference, even inside a closure.
Grouping changes call semantics: (receiver.name)() calls the accessor’s result as a value. It is not another spelling of receiver.name(). Named members, calls, and .N share postfix precedence and chain left to right. Neither named members nor tuple indices support assignment.
Hosts supply member signatures, not a fixed set of receiver types. The checker rejects known incompatible operands and preserves registered result types. Calls without metadata remain best-effort and still check every argument.
A bare closure is a complete expression, not an operator operand. Group it before applying an operator or postfix suffix: (|x: i32| x + 1)(2).
+ accepts homogeneous numeric operands and String + String. Unsigned integer addition wraps. Signed integer addition reports arithmetic overflow on overflow.
Binary - accepts homogeneous numeric operands. Unary - accepts only signed integers and floating-point values. Unsigned integer subtraction wraps. Signed binary subtraction and signed unary negation report arithmetic overflow on overflow.
* accepts homogeneous numeric operands. Unsigned integer multiplication wraps. Signed integer multiplication reports arithmetic overflow on overflow.
/ and % accept homogeneous numeric operands. Floating-point division and remainder use normal floating-point behavior. Integer failures report division by zero.
&, |, and ^ accept homogeneous integer operands only.
<< and >> accept integer operands only. The right operand must fit in u32, and the shift count must be in range. Shift failures report shift overflow.
! accepts bool only.
&& and || accept bool operands only and short-circuit.
== and != accept homogeneous numeric operands, homogeneous bool, or homogeneous String.
<, <=, >, and >= accept homogeneous numeric operands or homogeneous String.
The valid range forms are a..b, a..=b, a.., ..b, ..=b, and ...
..= always requires a right endpoint.
Range endpoints are or_expressions. Group a closure or nested range used as an endpoint; endpoint types must still satisfy the operator’s requirements.
Range expressions do not chain, so 1..2..3 is not valid.
1 + 2..3 * 4 means (1 + 2)..(3 * 4).
as converts a value to one of the sixteen built-in scalar type names: i8, i16, i32, i64, i128, isize, u8, u16, u32, u64, u128, usize, f32, f64, bool, and String.
Integer targets accept integer, floating-point, and bool sources. Floating-point targets accept integer and floating-point sources. bool and String targets accept only their same-type sources.
Integer-to-integer casts check that the source fits in the target. Floating-point-to-integer casts require a finite, in-range source and truncate toward zero. f64 as f32 checks finite range before narrowing.
true casts to integer 1, and false casts to integer 0.
char, byte-string, C-string, unit, array, tuple, range, and closure values are not additional cast target names.
Number-to-bool, bool-to-float, and String-to-number or String-to-bool casts are not valid.
Casts associate from left to right, so x as T as U applies the first cast before the second.

Edge cases

Write a < b && b < c, not a < b < c.
Call argument lists do not accept a trailing comma.
Negative shift counts, counts larger than u32, and counts outside the left operand’s width report shift overflow.
Signed +, signed binary -, signed unary -, and signed * overflows report arithmetic overflow.
Integer / and % report division by zero when they fail.
Casts cannot target char, byte-string, C-string, unit, array, tuple, range, or closure values.

Conditional expressions

CEL uses if expressions to select a branch value. For the exact grammar, see the Reference Manual.

Concept

An if expression selects one branch value. It is an ordinary expression and can appear anywhere an expression is expected.

Syntax

if_expression = "if" expression "{" expression "}"
              [ "else" ( "{" expression "}" | if_expression ) ] .

Worked examples

if ready { 1 } else { 0 }
if score > 90 { "high" } else if score > 75 { "mid" } else { "low" }

Exact rules

CEL supports the branch forms if, if ... else, and if ... else if ... chains.
The condition reserves the following body brace. Parenthesize a record constructor in the condition, such as if (Point { x: 0.0 }).x == 0.0 { 1 } else { 2 }. Branch bodies are ordinary expressions.
Omitting the final else supplies an implicit () branch, so the remaining branches must still be type-compatible with unit.
The braces belong to if syntax. CEL does not use free-standing block expressions.

Edge cases

if flag { () } else if other { () } is valid without a final else because the omitted branch is also ().

Collections

CEL uses tuples for fixed positional values and arrays for homogeneous sequences. An empty array uses a type annotation to state its element type. For the complete grammar, see the Reference Manual.

Concept

Parentheses and brackets build different kinds of values. Parentheses can mean unit, grouping, or tuples. Brackets always mean arrays.

Syntax

tuple_or_group = "(" [ expression [ "," [ expression { "," expression } ] ] ] ")" .
array_expression = "[" [ expression { "," expression } ] "]"
                 [ ":" type_expr ] .
type_expr = identifier [ "(" [ type_expr { "," type_expr } ] ")" ]
          | "[" type_expr "]"
          | "(" [ type_expr [ "," [ type_expr { "," type_expr } ] ] ] ")" .

Worked examples

(1,)
(1, 2, 3)
[0, 1, 2]
[[0], [1]]
[0, 1]: [i32]
[]: [i32]
[]: [[i32]]
[(7, [1.5]), (8, []: [f64])]
[]: [(i32, [f64])]
[]: [Fn((i32,), [i32])]
if ready { [1, 2] } else { [3, 4] }

Exact rules

() is unit, (expr) is grouping, (expr,) is a 1-tuple, and (a, b, c) is a tuple.
[a, b, c] is an array literal.
An unannotated array is non-empty and every element must have the same type.
A type annotation after : states the complete array type. It permits an empty array, as in []: [i32].
A non-empty array annotation must match the element type exactly.
Nested arrays are valid when each element is itself an array of the same element type.
Tuple indexing uses an unsuffixed integer such as .0 or .1. Named postfixes such as value.name invoke host-provided operations; they do not select tuple fields.
Arrays and tuples compose recursively over registered leaves, unit, other containers, and callables. Callable element types include their complete parameter and result shapes; storing a callable does not require equality.

Rust interoperability

CEL values map recursively to concrete Rust values:

CEL shape	Rust value	Representation witness
registered leaf `T`	`T`	`Leaf<T>`
`[T]`	`Array<R(T)>`	`ArrayOf<W(T)>`
`()`	`CNil<()>`	`Nil`
`(T, U)`	`CStackList<R(T), CStackList<R(U), CNil<()>>>`	`Cons<W(T), Cons<W(U), Nil>>`
`Fn((A,), R)`	`Callable<CStackList<R(A), CNil<()>>, R(R)>`	`FnOf<Cons<W(A), Nil>, W(R)>`

Here R(T) is the recursively canonical value and W(T) its witness. IntoCStackList and IntoRustTuple move between lists and ordinary Rust tuples without requiring Clone, equality, or formatting. Logical list order is source order.

This executable example prepares an array of actual lists, then moves each row into a native Rust tuple:

#![allow(unused)]
fn main() {
/// Moves concrete tuple-list elements out of an interpreted array in source order.
#[test]
fn arrays_of_tuple_lists() {
    use cel_parser::{CELParser, OpLookup};
    use cel_runtime::{ArrayOf, Cons, IntoCStackList, IntoRustTuple, Leaf, Nil};

    type Row = Cons<Leaf<i32>, Cons<ArrayOf<Leaf<f64>>, Nil>>;
    let body = CELParser::new(OpLookup::new())
        .parse_str("[(7, [1.5, 2.5]), (8, []: [f64])]")
        .unwrap();
    let mut body = body.prepare::<Nil, ArrayOf<Row>>().unwrap();
    let rows = body.call(&().into_c_stack_list()).unwrap();
    let actual: Vec<_> = rows
        .into_vec()
        .into_iter()
        .map(|row| {
            let (id, values) = row.into_rust_tuple();
            (id, values.into_vec())
        })
        .collect();
    assert_eq!(actual, [(7, vec![1.5, 2.5]), (8, vec![])]);
}
}

Nested vectors and slices

Array<T>::from_vec and into_vec transfer the allocation in O(1); as_slice borrows the same elements as &[T].

The representation of [[i32]] is Array<Array<i32>>. Its allocation-preserving vector view is Vec<Array<i32>>, and its slice view is &[Array<i32>], not Vec<Vec<i32>> or &[Vec<i32>]. An explicit deep conversion builds a new outer vector while transferring each inner allocation independently:

#![allow(unused)]
fn main() {
/// Transfers the outer allocation to a vector of canonical inner arrays.
#[test]
fn nested_array_vector_view() {
    use cel_parser::{CELParser, OpLookup};
    use cel_runtime::{Array, ArrayOf, IntoCStackList, Leaf, Nil};

    let body = CELParser::new(OpLookup::new())
        .parse_str("[[1, 2], []: [i32], [3]]")
        .unwrap();
    let mut body = body.prepare::<Nil, ArrayOf<ArrayOf<Leaf<i32>>>>().unwrap();
    let rows: Array<Array<i32>> = body.call(&().into_c_stack_list()).unwrap();
    let pointer = rows.as_slice().as_ptr();
    let capacity = rows.capacity();
    let rows: Vec<Array<i32>> = rows.into_vec();
    assert_eq!(rows.as_ptr(), pointer);
    assert_eq!(rows.capacity(), capacity);
    assert_eq!(rows[0].as_slice(), [1, 2]);
    assert!(rows[1].is_empty());
    assert_eq!(rows[2].as_slice(), [3]);

    // Deep conversion moves each inner allocation, but builds a new outer vector.
    let native: Vec<Vec<i32>> = rows.into_iter().map(Array::into_vec).collect();
    assert_eq!(native, [vec![1, 2], vec![], vec![3]]);
}
}

One operation for native and interpreted callers

op1_repr binds complete canonical witnesses, op1_vec moves an array into an owned vector for a callback, and op1_slice borrows its elements for the callback without consuming or rebuilding their allocation to obtain the borrow. The operation still owns its operand and drops it after the slice callback. The following ordinary Rust function serves both native construction and CEL. register_function binds its ordinary-call name; register_operation supplies the complete signature and emitter:

#![allow(unused)]
fn main() {
use cel_runtime::{Array, CNil, CStackList};

/// Names the actual Rust value of a CEL `(i32, bool)`, not its witness.
type RowValue = CStackList<i32, CStackList<bool, CNil<()>>>;

/// Reverses rows without cloning their elements.
///
/// - Complexity: O(n) time for n rows; preserves the vector allocation.
fn reverse_rows(mut rows: Vec<RowValue>) -> Array<RowValue> {
    rows.reverse();
    Array::from_vec(rows)
}

/// Uses one concrete Rust operation from native construction and interpreted CEL.
#[test]
fn shared_native_and_interpreted_operation() {
    use cel_parser::{CELParser, OpLookup, OperationSignature, builtin_type_resolver};
    use cel_runtime::{ArrayOf, Cons, IntoCStackList, IntoRustTuple, Leaf, Nil};

    type Row = Cons<Leaf<i32>, Cons<Leaf<bool>, Nil>>;
    let native = reverse_rows(vec![
        (7, true).into_c_stack_list(),
        (8, false).into_c_stack_list(),
    ]);
    let shape = CELParser::new(OpLookup::new())
        .parse_type_expr_str("[(i32, bool)]")
        .unwrap()
        .resolve(builtin_type_resolver().as_ref())
        .unwrap();
    let mut lookup = OpLookup::new();
    /// Binds the operation's ordinary-call name separately from its signature.
    #[derive(Clone)]
    struct ReverseRows;
    lookup
        .register_function("reverse_rows", ReverseRows)
        .unwrap();
    lookup
        .register_operation(OperationSignature {
            name: "reverse_rows",
            operands: vec![shape.clone()],
            result: shape,
            emit: Box::new(|body, _| body.op1_vec::<Row, ArrayOf<Row>, _>(reverse_rows)),
        })
        .unwrap();
    let body = CELParser::new(lookup)
        .parse_str("reverse_rows([(7, true), (8, false)])")
        .unwrap();
    let mut body = body.prepare::<Nil, ArrayOf<Row>>().unwrap();
    for rows in [native, body.call(&().into_c_stack_list()).unwrap()] {
        let actual: Vec<_> = rows
            .into_vec()
            .into_iter()
            .map(IntoRustTuple::into_rust_tuple)
            .collect();
        assert_eq!(actual, [(8, false), (7, true)]);
    }
}
}

Checked boundaries and prepared execution

ValueType records complete identity, layout, ownership, and optional capabilities. ResolvedType and the checker type Ty retain recursive shapes, including callable signatures.

OwnedValue::try_into_typed checks arbitrary external ownership against a full witness. DynSegment::prepare::<Args, Result> instead checks a typed frame once and produces PreparedSegment; its repeated call borrows canonical arguments and returns independent owners without descriptor comparisons, downcasts, or per-element validation. Hosts with runtime-bound storage can use prepared_segment::PreparedRawSegment: construction checks descriptors, but its unsafe call requires exact, live, aligned pointers for that prepared frame. Neither API removes value-dependent bounds checks or body errors.

Clone, equality, and debug formatting are separate capabilities. Construction and moving ownership do not require them; borrowing an emitted argument read requires cloning, and requesting comparison or formatting requires the matching capability.

Edge cases

[] is not valid because an empty array needs a type annotation.
[0,] is not valid.
[]: [i32] is a valid typed empty array.
[0, true] is not valid because the element types differ.
[(0, 1)] and []: [(i32, i32)] are valid tuple arrays.
[]: [[i32]] is a valid typed empty nested array.
[(0,), (true,)] is invalid because the complete element shapes differ.
Bracket postfix indexing such as items[0] is not part of the language.
A suffixed tuple index such as .0i32 is not valid.

Closures

CEL uses |...| for closure literals. A bare closure occupies a complete expression; an operator operand requires parentheses around the closure. For the exact grammar, see the Reference Manual.

Concept

A closure packages a parameter list and a single expression body into a callable value.

Syntax

expression = closure_expression | range_expression .
closure_expression = ("||" | "|" closure_param { "," closure_param } "|")
                     expression .
closure_param = identifier ":" type_expression .
type_expression = identifier [ "(" [ type_expression { "," type_expression } ] ")" ]
                | "[" type_expression "]"
                | "(" [ type_expression [ "," [ type_expression { "," type_expression } ] ] ] ")" .

Worked examples

|x: i32| x + 1
|pair: (i32, i32)| pair.0 + pair.1
|| 1..=5
(|x: f64| x)(1.0)
(|pair: (i32, i32)| pair.0 + pair.1)((2, 3))
(|rows: [[i32]]| rows)([[1], [2]])
|f: Fn((i32,), [i32])| f(42)
[]: [Fn((i32,), [i32])]

Exact rules

|| body declares a zero-parameter closure; spaced empty pipes | | are not this token.
|name: Type| body declares one typed parameter.
|a: T, b: U| body declares multiple typed parameters in source order.
An annotation uses the host’s configured type environment: built-in scalars and generic types, registered cloneable leaves, recursive tuple types, recursive array types, and structural Fn signatures. Container shapes require no separate registration.
|pair: (i32, i32)| pair.0 + pair.1 declares one tuple-typed parameter, not two separate parameters.
The closure body is one expression.
A bare closure body extends to its enclosing expression boundary. For example, || 1 + 2 returns 3; write (|| 1)() to apply a zero-parameter closure.
Group a closure before using it as an operator operand, cast input, or postfix receiver. a + |x: i32| x is a syntax error; a + (|x: i32| x) is syntactically valid, with operator/type checking performed separately.
Call arguments, tuple and array elements, branch bodies, and closure bodies are complete expressions and accept bare closures, as in f(|x: i32| x + 1).
Parameter names are unique and cannot use reserved value names.
A closure body resolves its own parameters and does not capture free variables from an enclosing expression. Installed library operations remain available inside it.
Parenthesize a closure to invoke it immediately. CEL checks the exact parameter and result shapes, including nested tuples and array element types. Arguments evaluate once, left to right; body errors propagate to the enclosing evaluation.
Known signatures travel through nested calls and tuple intermediates. Conditional closure alternatives must have identical known signatures. An opaque host-provided closure with no known signature reports an unsupported-call error rather than guessing a result type. A host may still supply its own call operation, which takes precedence.

Host registration

CELParser::with_type_resolver supplies annotation lookup. A registered leaf uses ValueType::cloneable_leaf::<T>() so parameters can clone owned values without requiring Copy, equality, or debug formatting. Adam supplies these descriptors through TypeRegistry. Results move from the body into the caller and need no clone adapter of their own.

The Rust DynClosure::new, call, and call_boxed APIs support host integrations. DynClosure::typed and DynSegment::push_closure retain the complete metadata needed by general CEL invocation.

Typed callable interoperability

Fn((A, B), R) has two parameters, Fn((A,), R) has one, and Fn((), R) has none. The parameter list is always a tuple type: Fn(A, R) does not stand for one parameter. A parameter can itself be a tuple, array, or callable. Arrays compare whole signatures when checking element homogeneity.

Callable<Args, R> uses concrete canonical list arguments and an owned result. FnOf<ArgsWitness, ResultWitness> supplies its complete structural witness. Callable::from_fn binds a native function pointer; Callable::from_prepared binds a matching PreparedSegment. Both expose the same call(&args) interface with no signature comparisons during invocation. Clones share execution state; recursive entry into the same carrier returns an error. Body errors propagate.

This example checks a typed empty array and calls native and interpreted functions through the same Rust interface. Callables need no equality capability to be array elements:

#![allow(unused)]
fn main() {
/// Preserves complete callable signatures even in empty arrays, without equality.
#[test]
fn typed_callable_arrays() {
    use cel_parser::{CELParser, OpLookup};
    use cel_runtime::{
        Array, ArrayOf, CNil, CStackList, Callable, Cons, FnOf, IntoCStackList, Leaf, Nil,
    };

    type Args = Cons<Leaf<i32>, Nil>;
    type Function = FnOf<Args, ArrayOf<Leaf<i32>>>;
    let mut parser = CELParser::new(OpLookup::new());
    let empty = parser.parse_str("[]: [Fn((i32,), [i32])]").unwrap();
    let mut empty = empty.prepare::<Nil, ArrayOf<Function>>().unwrap();
    assert!(empty.call(&().into_c_stack_list()).unwrap().is_empty());

    let body = parser.parse_str("[|x: i32| [x]]").unwrap();
    let mut body = body.prepare::<Nil, ArrayOf<Function>>().unwrap();
    let interpreted = body.call(&().into_c_stack_list()).unwrap();
    let native =
        Callable::from_fn(|args: &CStackList<i32, CNil<()>>| Ok(Array::from_vec(vec![args.1])));
    for function in [native, interpreted.into_vec().pop().unwrap()] {
        assert_eq!(
            function
                .call(&(42,).into_c_stack_list())
                .unwrap()
                .as_slice(),
            [42]
        );
    }
}
}

Edge cases

Closure parameter lists do not accept a trailing comma.
(i32,) is a one-element tuple type; (i32) groups the scalar type.
Closure bodies do not introduce statement blocks or local binding syntax.

Standard library

These numeric operations are opt-in: the evaluation environment must install cel-std with cel_std::install on its operation lookup. Without that installation, the operations in this chapter are unavailable; the core language still works unchanged. Installed operations support both ordinary and receiver calls: sqrt(x) and x.sqrt() select the same operation. The receiver supplies the first argument, so atan2(y, x) is also y.atan2(x).

The descriptive signatures below use type-family shorthand, not CEL generics:

Shorthand	Supported concrete types
`T`	`i8`, `i16`, `i32`, `i64`, `i128`, `isize`, `u8`, `u16`, `u32`, `u64`, `u128`, `usize`, `f32`, `f64`
`S`	`i8`, `i16`, `i32`, `i64`, `i128`, `isize`, `f32`, `f64`
`F`	`f32`, `f64`

Each occurrence of a shorthand in one call denotes the same concrete type. There is no implicit numeric conversion: for example, min(1i32, 2i64) has no matching overload. Unsupported types and arities fail during expression compilation, rather than producing the evaluation errors documented below. Scalar return types match the floating-point or numeric operand type; even rounded results remain floats. powi takes an i32 exponent, and sin_cos returns a tuple whose two elements have the input float type. Unsuffixed floating-point literals in the examples have type f64.

NaN and infinity below describe floating-point values, not CEL literal spellings. Operations that produce NaN do not report an evaluation error unless an entry explicitly says otherwise. NaN payloads and signs are not promised. Float operations delegate to the corresponding Rust f32 or f64 method. Transcendental results have Rust’s unspecified precision, which can vary across platforms and Rust versions; compare approximate results with a tolerance. Each operation takes O(1) time and space.

`min`

min(a: T, b: T) -> T

Selects the smaller of two same-type numeric values.

Parameters

Parameter	Description
`a`, `b`	Values to compare, both of the same type `T`.

Parameter	Description
`x`	Value to restrict.
`lo`	Inclusive lower bound, of the same type as `x`.
`hi`	Inclusive upper bound, of the same type as `x`.

Parameter	Description
`x`	The value whose logarithm is computed.
`base`	The logarithm base, normally positive and unequal to `1.0`.

Parameter	Description
`a`, `b`	Two points, two vectors, or two sizes.
`point`, `offset`	A position and the displacement to subtract.

Parameter	Description
`value`	A vector or size.
`factor`	The scalar multiplier or divisor.

Keyboard shortcuts

The Common Expression Language