Cameleon language Part 1: Processor

Emergence is the way complex systems arise out of a multiplicity of relatively simple interactions between primitives. Since programming problems become more and more complexes and transverses, our vision is that application development should be process at two scales: micro- and macro-programming where at the micro-level the paradigm is step-by-step and at macro-level the paradigm is emergence. For micro-programming, which focuses on how things happen, popular languages, Java, C++, Python, are imperative writing languages where the code is a sequence of sentences executed by the computer. For macro-programming, which focuses on how things connect, popular languages, labVIEW, Blender, Simulink, are graphical data flow languages such that the program is a composition of operators, a unit-process consuming input data and producing output data, and connectors, a data-flow between an output data and an input data of two operators. However, despite their fruitful applications, these macro-languages are not transversal since different data-structures of native data-structures cannot be integrated in their framework easily. Cameleon language is a graphical data flow language following a two-scale paradigm. It allows an easy up-scale that is the integration of any library writing in C++ in the data flow language. Cameleon language aims to democratize macro-programming by an intuitive interaction between the human and the computer where building an application based on a data-process and a GUI is a simple task to learn and to do. Cameleon language allows conditional execution and repetition to solve complex macro-problems. In this paper we introduce a new model based on the extension of the petri net model for the description of how the Cameleon language executes a composition.

💡 Research Summary

The paper introduces the Cameleon language, a graphical data‑flow programming environment that simultaneously supports micro‑programming (step‑by‑step, imperative coding) and macro‑programming (emergent, data‑flow composition). The authors argue that modern software problems are increasingly complex and transversal, requiring a two‑scale approach: developers write low‑level algorithms in C++ (micro‑scale) while assembling high‑level applications by dragging and connecting operators in a visual editor (macro‑scale). Existing macro‑languages such as LabVIEW, Simulink, Blender, or Quartz Composer excel at visual composition but suffer from poor transversality because native data structures from external libraries cannot be easily integrated. Cameleon addresses this by providing a simple “up‑scale” mechanism: developers register a data dictionary, input and output handlers, and an operator dictionary that wraps any C++ library function as a black‑box operator.

The core technical contribution is an extended Petri‑net model that defines the execution semantics of Cameleon programs. A program is a 4‑tuple (D, Op, I, O) where D is a set of data tokens, Op a set of operators, I maps each operator to its input data, and O maps each operator to its output data. The model introduces three token states: void (0), old (1), and new (2). A marking function µₜ assigns a state to each data element at time t. Execution of an operator op at time t is permitted only if (1) every input data contains a token (old or new), (2) at least one input token is new, and (3) none of the output data already contain a new token. This predicate eₒₚ is expressed formally and evaluated each cycle.

When an operator fires, a process function fₒₚ computes new values for its output data based on the current values of its inputs. After computation, an update function uₒₚ changes the token states: inputs become old (1) and outputs become new (2). This explicit token lifecycle enables the model to represent conditional execution and loops without proliferating a large number of Petri‑net places and transitions, which is a known limitation of classical Petri‑nets for such constructs.

The execution engine (processor) repeatedly selects executable operators. To avoid nondeterminism, it chooses the operator that has been waiting the longest; if several share the same waiting time, the one with the smallest index is selected. The engine also supports concurrent execution of non‑adjacent operators, preventing race conditions by ensuring that two operators sharing any input or output cannot run simultaneously.

The paper defines several primitive operators that together form a small but expressive library for macro‑programming:

• If/Else – two inputs (data and Boolean condition) and two mutually exclusive outputs (if‑branch, else‑branch). The condition determines which output receives the copied data and a new token.
• Merge – two inputs, one output; the operator copies the input that carries a new token to the output and marks the input token as old.
• Synchrone – two inputs, two outputs; fires only when both inputs are new, copying each input to its corresponding output.
• Increment – no inputs, one numeric output; each firing increments the output value, useful for loop counters.
• Less‑Than (<) – two numeric inputs, one Boolean output; evaluates the comparison and produces a Boolean token.

By combining these primitives, users can construct conditional branches, loops, and synchronization patterns graphically, achieving the same expressive power as traditional control‑flow constructs while remaining within the data‑flow paradigm.

The authors conclude that the extended Petri‑net semantics provide a mathematically precise yet practical foundation for a macro‑programming language that is both transversally integrable (through C++ up‑scaling) and accessible to non‑programmers via a visual interface. They acknowledge that token management and scheduling complexity may affect performance in large‑scale or real‑time scenarios, suggesting future work on optimization, scalability, and richer concurrency models.