FROG

<div class="go-pages-link" data-render-target="github"> <a href="https://graiphic.github.io/FROG/"> <img src="./assets/open-github-pages-banner.svg" alt="Open the GitHub Pages version" /> </a> </div> <p align="center"> <img src="FROG logo.svg" alt="FROG logo" width="140" /> </p> <h1 align="center">🐸 FROG — Free Open Graphical Language</h1> <p align="center"> <strong>Free Open Graphical Dataflow Programming Language</strong><br/> FROG is an open, hardware-agnostic graphical dataflow programming language designed to describe computation as explicit executable graphs while remaining accessible, explicit, inspectable, portable, auditable, and scalable across heterogeneous execution targets. </p> <p align="center"> Specification work initiated: <strong>8 March 2026</strong> </p> <p align="center"> <a href="#what-is-frog">What is FROG?</a> • <a href="#what-this-repository-defines">What this repository defines</a> • <a href="#published-repository-state">Published repository state</a> • <a href="#campaign-priority">Campaign priority</a> • <a href="#positioning">Positioning</a> • <a href="#breaking-the-syntax-first-bottleneck">Breaking the syntax-first bottleneck</a> • <a href="#why-frog-exists">Why FROG exists</a> • <a href="#frog-in-the-ai-era">FROG in the AI era</a> • <a href="#dataflow-programming">Dataflow programming</a> • <a href="#from-prototyping-to-critical-systems">From prototyping to critical systems</a> • <a href="#core-concept-diagram-front-panel-and-public-interface">Core concept</a> • <a href="#repository-structure">Repository structure</a> • <a href="#repository-runtime-and-native-execution-direction">Runtime and native execution direction</a> • <a href="#internal-documentation-map">Internal documentation map</a> • <a href="#recommended-reading-path">Recommended reading path</a> • <a href="#specification-architecture">Specification architecture</a> • <a href="#specification-versioning">Specification versioning</a> • <a href="#program-representation">Program representation</a> • <a href="#execution-architecture">Execution architecture</a> • <a href="#execution-observability-debugging-and-inspection">Execution observability, debugging, and inspection</a> • <a href="#execution-targets">Execution targets</a> • <a href="#open-industrial-hardware-standard">Open industrial hardware standard</a> • <a href="#security-and-optimization-by-design">Security &amp; optimization</a> • <a href="#interoperability">Interoperability</a> • <a href="#separation-of-language-and-tooling">Language separation</a> • <a href="#governance-and-ecosystem">Governance and ecosystem</a> • <a href="#project-status">Project status</a> • <a href="#license">License</a> </p> <hr/> <h2 id="what-is-frog">What is FROG?</h2> <p> FROG is an open, hardware-agnostic <strong>graphical dataflow programming language</strong>. It represents computation as explicit executable graphs rather than as syntax-first sequences of textual instructions. </p> <p> Instead of describing a program primarily through ordered text, FROG describes a program through: </p> <ul> <li>typed nodes,</li> <li>typed ports,</li> <li>directed graph connections,</li> <li>structured control regions,</li> <li>explicit public interface boundaries,</li> <li>optional front-panel widgets and interaction layers.</li> </ul> <p> Execution emerges from data availability, dependency structure, explicit control constructs, intrinsic standardized primitive behavior, optional profile-owned capability behavior, and explicit local-memory semantics rather than from manually authored instruction order. </p> <p> FROG is designed to remain independent from any specific IDE, compiler, runtime, operating system, or hardware vendor. That separation provides a durable basis for multiple independent implementations, long-term industrial interoperability, and auditable portability across toolchains. </p> <p> FROG is intended to scale from accessible graphical authoring to demanding execution contexts such as industrial automation, embedded systems, heterogeneous compute targets, and future conforming execution ecosystems. </p> <hr/> <h2 id="what-this-repository-defines">What this repository defines</h2> <p> This repository defines the <strong>published FROG specification</strong>. It is the repository where the language and its surrounding specification layers are written, clarified, stabilized, versioned, and progressively closed. </p> <p> Its role is to provide a durable open foundation for future: </p> <ul> <li>IDEs,</li> <li>validators,</li> <li>runtimes,</li> <li>compilers,</li> <li>execution backends,</li> <li>profile-supporting toolchains,</li> <li>ecosystem services and integrations.</li> </ul> <p> The repository also contains repository-level support material that helps make the specification inspectable in practice: named examples, conformance material, a non-normative reference implementation workspace, a strategic framing layer, a non-normative roadmap layer, and a centralized specification-versioning surface. Those areas support the published specification, but they do not replace its ownership boundaries. </p> <p> This repository does <strong>not</strong> define one mandatory product implementation. It does not equate the language with one IDE, one runtime, one compiler, one vendor stack, or one deployment model. </p> <ul> <li><strong>FROG is not an IDE.</strong></li> <li><strong>FROG is not a single runtime.</strong></li> <li><strong>FROG is not a single compiler.</strong></li> <li><strong>FROG is not a vendor product.</strong></li> <li><strong>FROG is an open language specification with distinct source, semantic, FIR, library, profile, IDE-facing, conformance, and version-governance layers.</strong></li> </ul> <hr/> <h2 id="published-repository-state">Published repository state</h2> <p> At the current published state, the repository already contains the six core architectural specification families: <code>Expression/</code>, <code>Language/</code>, <code>IR/</code>, <code>Libraries/</code>, <code>Profiles/</code>, and <code>IDE/</code>. These remain the primary ownership layers of the published language specification. </p> <p> The repository also contains repository-level support areas and repository-level framing / governance layers: </p> <ul> <li><strong><code>Examples/</code></strong> — illustrative named source slices, applicative vertical-slice anchors, and bounded compiler-corridor mirrors,</li> <li><strong><code>Conformance/</code></strong> — public accept / reject / preserve expectations for the published repository state,</li> <li><strong><code>Implementations/Reference/</code></strong> — a non-normative reference implementation workspace used to exercise disciplined execution paths,</li> <li><strong><code>Versioning/</code></strong> — centralized specification-version governance and current-status reporting for the published specification corpus,</li> <li><strong><code>Strategy/</code></strong> — a non-normative strategic framing layer distinct from normative ownership,</li> <li><strong><code>Roadmap/</code></strong> — a non-normative closure-sequencing layer distinct from both strategy and specification.</li> </ul> <p> The published example surface already contains both: </p> <ul> <li>a numbered example-slice progression under <code>Examples/01_*</code> through <code>Examples/05_*</code>,</li> <li>and a narrower conservative compiler-corridor mirror under <code>Examples/compiler/</code>.</li> </ul> <p> The first repository-visible applicative vertical-slice anchor is: </p> <pre><code>Examples/05_bounded_ui_accumulator/</code></pre> <p> That slice is currently the primary named source-to-contract-to-runtime anchor because it visibly combines: </p> <ul> <li>front-panel participation,</li> <li>widget-value participation,</li> <li>minimal widget-reference participation,</li> <li>bounded structured control,</li> <li>explicit local state,</li> <li>public output publication,</li> <li>a published backend contract artifact,</li> <li>and published downstream reference runtime consumers.</li> </ul> <p> The current published runtime surface already includes: </p> <ul> <li>a repository-visible runtime directory under <code>Implementations/Reference/Runtime/</code>,</li> <li>a Python execution entry point for the published bounded slice,</li> <li>and a Rust runtime-side consumer posture under <code>Implementations/Reference/Runtime/rust/</code>.</li> </ul> <p> At the same time, the repository does <strong>not yet</strong> materially expose full symmetry between: </p> <ul> <li>Python mini runtime,</li> <li>Rust mini runtime,</li> <li>C/C++ mini runtime,</li> <li>and LLVM-oriented native executable closure.</li> </ul> <p> That distinction matters. The published direction already supports language/runtime separation, but the repository-visible executable closure still needs to become more explicit and more symmetrical across runtime families. </p> <hr/> <h2 id="campaign-priority">Campaign priority</h2> <p> The current campaign priority is explicit: <strong>close serious published examples all the way to real execution and make multi-runtime modularity repository-visible.</strong> </p> <p> A serious example is no longer considered finished merely because it is source-readable or architecturally plausible. A serious example should progressively converge toward: </p> <ul> <li>one canonical <code>.frog</code> source,</li> <li>one explicit front-panel posture,</li> <li>one explicit peripheral UI object realization file when applicable,</li> <li>one explicit FIR reading,</li> <li>one explicit lowering posture,</li> <li>one backend contract,</li> <li>one Python mini runtime path,</li> <li>one Rust mini runtime path,</li> <li>one C/C++ mini runtime path,</li> <li>and, where applicable, one