What's meshed about?

[thorwhalen]

Answering a senior architect

We’re taking a declarative approach that separates components, the structure of their relationship in a “composite component”, and the execution of this composite. This will enable us both to create no-code GUIs enabling customers to build data processing pipelines, but also maintain more reusability and flexibility as far as execution goes (e.g. being able to more easily run on the cloud, on-premises, or on the deep-edge, or a hybrid of them all).

[thorwhalen]

Answering a senior developer

The main idea of meshed is to provide tools to assist in the systematic assembly and operation of python objects.

By "assembly" we mean the definition of how the different python objects should interact.
Typically, we define this assembly by writing lines of code, feeding some values in one function, getting it's output,
combining with another value, and assigning that result to a variable, etc.

By "systematic" we mean "through a system", so "systematic assembly" means that the structure of this assembly is specified through a separate logic.

By "operation" we mean that we the ability to operation on, and with, the objects created.
For example, being able to add logging, or caching, or extra branches of computation to an already existing data flow.

The last important word to clarify: python objects.
Yes, this means that the scope is everything python, potentially.
Most of the time these objects will be callables though.
There's two main aspects in meshed tools:

• defining the relationship of a set of objects
• defining how use these relationships to execute, given these relationships

If at this point, you're in need a concrete image in mind, think of the computation DAG (direct acyclic graph),
pipelines, or even a simple composition of functions -- but know, as you have these instances in mind, that there could be many more such "assembly systems". Even so, the input-output relationship that a DAG represents could be executed in many different ways:

• as a single function computing leaf values from root values
• as a template to extract many different input-output functions from, for example
  • to make a class that fixes some attributes, then offers methods that depend on these
  • as the expression of linked user story actions
• as the structure of a reactive system (e.g. reactive programming, @property, @cached_property, ...)
• as a guideline on how to dynamically find a computational path from available resources to a desired resource

[thorwhalen]

Reactive Computation Framework Specification

Overview

We are building a framework that transforms user-defined relationships between variables into interactive, computable systems. The framework handles bidirectional dependencies and cycles gracefully, enabling users to express their mental models of how variables relate without worrying about computational ordering or infinite loops.

Core Components

1. Mesh Specification Layer

We define computational networks (which we call "meshes") using various input formats:

Input Sources:

• JSON specifications with explicit function definitions
• Python/JavaScript functions with introspected dependencies
• Excel formulas parsed from spreadsheet cells
• Natural language descriptions processed by AI agents to extract relationships
• Mathematical notation parsed from LaTeX or symbolic expressions
• Configuration files (YAML, TOML) with domain-specific syntax

All input sources compile to a unified mesh representation where:

• Variables represent data points or computed values
• Functions express relationships between variables
• Function argument names serve as source variable IDs
• Function names serve as target variable IDs
• Cycles are permitted (e.g., Y = f(X) and X = g(Y) can coexist)

2. Intermediate Representation (IR)

We compile mesh specifications into a static, optimized representation containing:

• Variable-to-function dependency mappings
• Topological ordering for acyclic portions
• Cycle detection and resolution strategies
• Computation scheduling indices

This IR eliminates the need for runtime dependency analysis and enables efficient execution across different rendering environments.

3. Execution Modules

We implement multiple execution environments from the same IR:

Computational Executors:

• Python callable objects for programmatic calculation
• JavaScript compute engines for web-based processing
• Excel workbooks with generated formulas and macros

Interactive Renderers:

• HTML/JS reactive pages with real-time updates via sliders and inputs
• Desktop applications with native UI controls
• Jupyter notebook widgets for exploratory analysis
• Web-based visualization dashboards

Export Formats:

• Static reports (PDF, HTML)
• API endpoints for external system integration
• Database schemas with computed columns

Key Innovation

Our system resolves bidirectional dependencies through constraint satisfaction rather than sequential computation, allowing the expression of natural relationships (like temperature_celsius = (temperature_fahrenheit - 32) * 5/9 alongside temperature_fahrenheit = temperature_celsius * 9/5 + 32) without computational conflicts.

Target Use Case

We prioritize creating interactive web applications where users can manipulate variable values and observe real-time propagation of changes throughout their defined system of relationships, while maintaining flexibility in how meshes are specified and executed.