RFC 015: Core scalar functions and operators

[dannymeijer]

Use this issue to track InQL RFC 015, which already exists at docs/rfcs/015_core_scalar_functions.md.

Area

• Specification (RFCs)
• Package & tests
• Documentation

Summary

RFC 015 defines the first required scalar function and operator slice for InQL: column references, literals, casts, comparisons, boolean logic, null checks, basic arithmetic, conditionals, membership predicates, range predicates, and ordering expressions.

Motivation

Typed dataframe and query-block authoring need a stable scalar vocabulary before broader math, string, date/time, nested, and format catalogs can be added coherently.

Proposal sketch

The RFC establishes the minimum scalar surface for credible typed authoring and keeps it aligned with RFC 012 and the RFC 014 registry model. It covers canonical function/operator meaning, typechecking expectations, lowering constraints, and diagnostics for the foundational scalar forms.

Implementation decisions now recorded in the RFC:

• Boolean helper names are and_, or_, and not_.
• try_cast has null-on-conversion-failure semantics for this RFC.
• Numeric promotion remains registry/type-metadata level for this package slice; no package-local promotion table is introduced here.
• in_ accepts literal or expression lists; relation-valued subqueries remain out of scope.
• Function/operator calls use one registry-backed scalar function application node, while ColumnRefExpr and literal nodes remain structural.

Alternatives considered

The RFC rejects waiting for the broad function catalog, keeping separate helper families for filter/projection expressions, and using backend SQL expression strings for all scalar expressions.

Impact / compatibility

This RFC affects scalar function documentation, package helpers, compiler query/operator lowering, Prism/Substrait expression lowering, and diagnostics around casts, comparisons, null-safe equality, boolean logic, and ordering null placement.

Implementation notes

RFC 014 is merged and treated as the registry/decorator baseline. Scalar entries should land as declaration-side registered catalog functions, not ad hoc helpers or a hardcoded central registry list.

Checklist

• I checked for an existing RFC or issue covering this.
• I can describe how this impacts existing code and how to migrate (if needed).

[dannymeijer]

Implementation constraint: registry-backed scalar applications

RFC 015 must replace bespoke scalar function/operator variants with registry-driven scalar function application where appropriate.

Acceptance:

• Keep structural scalar nodes for ColumnRefExpr and literals.
• Represent function/operator calls like add, multiply, eq, gt, later and_, or_, cast, etc. as registry-backed scalar function applications, not one model per function forever.
• Substrait lowering resolves through the registered function spec/mapping instead of hardcoded per-variant anchors.
• Public kind/docs/type metadata derives from the registry entry, not a second hand-maintained column_expr_kind match.
• Tests prove adding one scalar function requires adding the registry entry and targeted function behavior, not editing separate kind/lowering switchboards.

[dannymeijer]

RFC 015 is moving into implementation.

Baseline: RFC 014 is merged and treated as the registry/decorator baseline.

Implementation notes now recorded in the RFC:

• Keep structural scalar nodes for column references and literals.
• Replace bespoke function/operator expression variants with a registry-backed scalar function application node.
• Register the core scalar helper slice through declaration-side @FUNCTION_REGISTRY.add(...) metadata.
• Preserve existing honest Substrait lowerings and mark unsupported helpers explicitly in registry metadata.
• Keep typed literal helpers routed through the canonical literal representation.

[dannymeijer]

Blocked on Incan compiler bug dannys-code-corner/incan#671.

While implementing RFC 015, we decided the cleaner InQL shape is a src/functions/mod.incn facade plus one public helper per src/functions/<name>.incn module, with rich helper docs and inline module tests: close to the implementation. That shape requires each helper module to register with one shared imported package registry via @FUNCTION_REGISTRY.add(...).

A minimized repro shows decorators on imported static registry receivers currently emit invalid Rust for str arguments (&str is passed where String is expected). This blocks the requested split-module registry design without either duplicating registries or abandoning declaration-side decorator registration.

Current InQL worktree has partial pre-blocker WIP for the shared scalar application node and metadata/lowering tests, but the implementation should resume after #671 is fixed and be reshaped into the per-helper module layout.