OOPSLA 2026

Interactive Data Analysis
with Lively Typed Tables

Alexander Bandukwala · Cyrus Omar

University of Michigan's Future of Programming Lab

Exploratory data analysis today

Exploring, cleaning and reshaping data in a live programming environment: writing code and running it are interleaved.

^† Out-of-order execution in notebooks: Pimentel et al., MSR 2019 · Chattopadhyay et al., CHI 2020

Types for table schemas

Fancy type systems

One answer is to make the type system richer

Our approach

1. Use static typing when convenient
2. Fall back to gradual typing when our static types are not enough buys expressivity · costs feedback
3. Introduce live typing provides the feedback static types cannot

We build on Hazel, a live and gradually typed programming environment.

Hazel Lab Hazel + structural operations + live typing + rich probes

Brown Benchmark for Table Types

B2T2 Lu, Greenman & Krishnamurthi 2022

Example tables, programs and error scenarios — and a Table API of 49 operations.

B2T2: Hazel

B2T2: Hazel Lab

Every operation is at least partially expressible, but most constraints go unchecked.

The paper also reports an intermediate ablation, Hazel with tuple extension.

^* four only partially expressible, e.g. leftJoin requires the right table to have at least one row

Live typing

In a live programming environment, we have dynamic values. We should use them to bolster static types.

1. Observe the values that reach each statically underspecified expression
2. Synthesize the type of each observed value
3. Combine those types with their meet falling back to the static type if they conflict
4. Re-check the program with the unknowns filled in

Statically, this program has no errors

? is consistent with every type, so static analysis has nothing to report.

let sum : [Int] -> Int = ... in
let to_string(d : (String, ?)) =
    case d                                           (String, ?)
    | ("int",  v) => string_of_int(v)                Int
    | ("bool", v) => string_of_int(v)                Bool
    | ("nums", v) => string_of_int(sum(v))           [Float]
    | (_,      v) => "Unknown: " ++ v                ?
    end
in
to_string("int", 1);
to_string("string", "hello");
to_string("bool", true);
to_string("nums", [1., 2.]);
map([("string", "world"), ("bool", false), ("nums", [])], to_string)

Is this just dynamic typing?

The opening example again, with a report that is never called.

let readings = [(id="MX17004", element="tmax", value="27.8"), …] in
let wide =                  [(index=String, tmax=String, tmin=String)]
  pivot_table(readings, …) in
let report() = wide.tmean in
length(wide)

Back to the benchmark

No extra annotations, and no richer types in the surface language.

Live typing doesn't help preconditions.

The paper also reports an intermediate ablation, Hazel with tuple extension.

^* four only partially expressible, e.g. leftJoin requires the right table to have at least one row

^† assumes each call returns a table with the same schema every time it runs

Rich probes for tables

A domain-specific view of a probed value, where direct manipulation edits the underlying syntax.

User study

An exploratory lab study with users familiar with statically typed functional programming. Not intended to assess transfer to data scientists without training.

Adoption intent questions

Every response at least neutral: 24 of 28 positive, none negative.

All seven were already fluent in statically typed functional programming.

Not intended to assess transfer to data scientists without that training, many of whom work in Python or R.

Related work

Future work

summary

Hazel Lab

• A gradually typed tabular programming system Conversions between labeled tuples and lists let a program compute with column names at runtime,
  relying on the unknown type when labels can't be determined statically.
• Live typing Values from the running program refine underspecified types, and the program is re-checked.
  Column accesses are checked against names that came from the data, including in functions that never ran.
• Rich probes for tables A probed value can be displayed as a table, with a menu of actions on each column.
  The actions rewrite the source code and leave typed holes when the user has to supply a value.

hazel.org/build/tables-study

Hazel Lab in your browser, start with the tutorial

Artifact on Zenodo: 10.5281/zenodo.21458220

Structural operations on labeled tuples

The same operations on a row whose type is unknown: let x : ? = (a=1, b=2, 3, c=4)

Tabular programming systems

No existing system addresses all five. Our own row is partial on distal feedback: live typing shortens the spatial distance and not the temporal one — you still wait for the program to finish.

Why the meet?

(Int, ?) ⊓ (?, String)  =  (Int, String)
(Int, ?) ⊔ (?, String)  =  (?, ?)

The unknown type is not any

let x : ? = "" in
let y = [x, 1] in …

const x : any = "";
const y = [x, 1];

How to_lvs is typed

A static error if the argument is not a tuple. Otherwise the value type is the meet of the entry types, falling back to the unknown type when they are inconsistent.

to_lvs((a=1, b=2, c=3))            ⤳ [(label=String, value=Int)]

to_lvs((a=?, b=1, c=?))            ⤳ [(label=String, value=Int)]

to_lvs((a=true, b=1, c=2.0))       ⤳ [(label=String, value=?)]

to_lvs((a=(true,?), b=(?,?), c=(?,1.0)))
                                   ⤳ [(label=String, value=(Bool, Float))]

The last case is the interesting one: the meet is computed pointwise, so partial information from several entries combines into a type more precise than any single entry supplied.

One function, two datasets

Applied to two datasets, the schemas are inconsistent, so no meet exists and the result keeps its static type — no marks. Each probe collects one value per invocation, so pinning one invocation restricts live typing to that call: the mark lands on Unknown for the first dataset and moves to Recreational for the second.

What makes this work in Hazel

• Every caller of a function is running in the same environment. The editor is not compiling a library against unknown future callers — it is observing this program, as currently written, with its actual inputs.
• Purity makes the runtime-derived types deterministic and reproducible, and continuous reevaluation keeps them current.
• The cost is dictated by how statically typed the program already is. The more precise your static types, the less there is for live typing to do.
• The flip side: if you were writing a library whose callers are elsewhere, the live types you observe need not match the ones your users would produce.

Column names as data

buildColumn(gradebook, "average-quiz", (row) => {
  const quizCols = header(row)
    .filter((c) => startsWith(c, "quiz"));

  const scores = quizCols
    .map((c) => getValue(row, c) as number);

  return sum(scores) / length(scores);
});

Live typing on buildColumn

The gradebook example: a new column named by a string, computed from the columns whose names start with quiz.