Free Open Graphical Dataflow Programming Language
FROG is an open, hardware-agnostic graphical dataflow programming language designed to describe computation as explicit executable graphs while remaining accessible, explicit, inspectable, portable, and scalable across heterogeneous execution targets.
Specification work initiated: 8 March 2026
What is FROG? • What this repository defines • Positioning • Breaking the syntax-first bottleneck • Why FROG exists • Dataflow programming • From prototyping to critical systems • Core concept • Repository structure • Internal documentation map • Recommended reading path • Specification architecture • Program representation • Execution architecture • Execution observability, debugging, and inspection • Execution targets • Open industrial hardware standard • Security & optimization • Interoperability • Language separation • Governance and ecosystem • Project status • License
FROG is an open, hardware-agnostic graphical dataflow programming language. It represents computation as explicit executable graphs rather than as syntax-first sequences of textual instructions.
Instead of describing a program primarily through ordered text, FROG describes a program through:
- typed nodes,
- typed ports,
- directed graph connections,
- structured control regions,
- explicit public interface boundaries,
- optional front-panel widgets and interaction layers.
Execution emerges from data availability, structural rules, explicit control structures, intrinsic standardized primitive behavior, optional profile-owned capability behavior, and explicit local-memory semantics rather than from manually authored instruction order.
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 and long-term industrial interoperability.
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.
This repository defines the published FROG specification. It is the repository where the language and its surrounding specification layers are written, clarified, stabilized, and progressively closed.
Its role is to provide a durable open foundation for future:
- IDEs,
- validators,
- runtimes,
- compilers,
- execution backends,
- profile-supporting toolchains,
- ecosystem services and integrations.
This repository does not 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.
- FROG is not an IDE.
- FROG is not a single runtime.
- FROG is not a single compiler.
- FROG is not a vendor product.
- FROG is an open language specification with distinct source, semantic, IR, library, profile, and IDE-facing layers.
FROG is designed to combine the accessibility of graphical programming with the execution depth required for deterministic, industrial, embedded, and high-performance systems.
Its ambition is to reduce the historical trade-off between:
- ease of expression,
- clarity of system design,
- deterministic execution,
- deployment scalability,
- hardware integration depth.
FROG aims to combine graphical accessibility, explicit dataflow, and system-grade execution in one open language model.
A major barrier in many traditional programming environments is that useful system design often begins only after a long period of syntax learning, pattern memorization, and language-specific implementation habits.
This creates an inversion: instead of starting from the system that should exist, developers often start from the syntax they already know how to write.
That inversion limits experimentation and slows architectural thinking. It encourages people to ask:
“What can I build with the implementation techniques I already master?”
rather than:
“What system should I build, and how should its behavior be expressed?”
FROG is designed to reduce that bottleneck by moving more of the developer’s effort toward:
- data movement,
- system structure,
- interfaces,
- control regions,
- state visibility,
- execution semantics.
The goal is not to eliminate engineering complexity. The goal is to shift complexity toward the system itself rather than toward syntax-first representation.
Graphical dataflow programming has already demonstrated major advantages in many engineering domains:
- natural parallelism,
- clear orchestration of behavior,
- strong correspondence between software structure and system behavior,
- high productivity for engineers, scientists, and domain experts,
- strong suitability for instrumentation, control, and observable systems.
However, many historical graphical environments have been tightly coupled to proprietary ecosystems where language, tooling, runtime, and hardware support are inseparable.
That model limits portability, slows independent ecosystem growth, and prevents multiple actors from implementing the same language cleanly.
FROG exists to define an open language specification for graphical dataflow programming that remains separate from:
- any single IDE,
- any single runtime,
- any single compiler,
- any single hardware vendor.
This repository therefore defines the language standard and the surrounding specification layers needed to support future conforming implementations. The objective is to make it possible for different actors to build compatible FROG tooling while targeting one shared open language definition.
FROG follows a true dataflow execution model.
In instruction-sequenced programming, execution is primarily described as ordered steps. In dataflow programming, operations become executable when their required input data is available.
Traditional execution A → B → C → D Dataflow execution A / \ B C \ / D
Execution order therefore emerges from dependencies rather than from manually authored textual ordering. This model enables:
- automatic parallelism where valid,
- clear dependency visibility,
- deterministic execution models where required,
- efficient mapping to heterogeneous hardware.
FROG is designed to support both rapid experimentation and demanding deployment.
The same programming model is intended to scale across domains such as:
- scientific computing,
- measurement and control,
- industrial automation,
- embedded systems,
- real-time control,
- microcontroller-oriented execution,
- accelerated and edge computing,
- high-performance systems.
Usability and execution depth are treated as complementary goals rather than mutually exclusive ones.
A FROG program combines multiple related but distinct source-level concepts. The repository deliberately separates them so that execution meaning, public API, and UI-facing authoring remain coherent over time.
The diagram defines the executable logic of the program. It is the authoritative source-level execution graph.
It contains:
- primitive nodes,
- structure nodes,
- sub-FROG invocations,
- interface boundary nodes,
- widget-related graph nodes,
- directed graph edges,
- source-level annotations and documentation.
The diagram expresses:
- ordinary computation,
- control structures such as
case,for_loop, andwhile_loop, - public interface participation through
interface_inputandinterface_output, - front-panel value participation through
widget_value, - object-style widget interaction through
widget_referenceandfrog.ui.*primitives, - optional profile-owned capability usage where supported by the active implementation,
- explicit local memory and valid cycles.
The public interface defines the typed reusable boundary of a FROG. It describes the inputs and outputs that matter when a FROG is invoked, embedded, reused, validated, documented, or integrated by other FROGs or tools.
The public interface is not owned by the front panel.
It is defined independently and participates in the diagram through interface_input and interface_output.
The front panel defines the graphical interaction layer of the program. It contains widget instances, layout information, composition, styling, and optional UI-library references.
The front panel is not the public API of the FROG and it is not the execution graph of the FROG. It defines how users see and interact with the program.
A FROG MAY exist without a front panel. When absent, the program remains a valid executable graphical artifact centered on its diagram and public interface.
Primary widget values participate naturally in execution through widget_value nodes in the diagram.
There is no separate canonical front-panel binding section for ordinary value flow.
FROG distinguishes two widget interaction paths:
- natural value path — widget primary value participation through
widget_value, - object-style path — explicit widget access through
widget_referencetogether withfrog.ui.property_read,frog.ui.property_write, andfrog.ui.method_invoke.
These two paths are related but distinct. This keeps ordinary dataflow wiring simple while preserving a clean long-term object model for UI interaction.
This repository is organized by architectural responsibility. Each top-level directory has a specific role in the specification.
FROG/
│
├── Expression/ Canonical source specification for .frog programs
├── Language/ Normative execution semantics for validated program meaning
├── IR/ Open execution-facing representation and downstream handoff boundaries
├── Libraries/ Intrinsic standardized primitive-library specifications
├── Profiles/ Optional standardized capability-family specifications
├── IDE/ IDE architecture, authoring, observability, debugging, and inspection
│
├── CLA.md Contributor license agreement requirements
├── CONTRIBUTING.md Contribution process and contribution rules
├── GOVERNANCE.md Governance, stewardship, and ecosystem model
├── FROG logo.svg Official logo asset
├── LICENSE Repository license
├── Readme.md Repository landing page and architectural overview
└── frog-orville-chart.png Positioning illustration used by the repository
This directory defines the canonical .frog source format.
It describes what a FROG source file contains, how source sections are represented, and how source-visible program objects are serialized.
This directory defines cross-cutting execution semantics for validated program meaning. It is the normative home of language meaning when that meaning cannot be owned by one isolated source section or one intrinsic primitive-library document alone.
This directory defines the architectural home of open, inspectable, specification-facing intermediate representations derived from validated program meaning. It sits between validated semantics and later lowering, backend mapping, compilation, or runtime-specific realization.
It also documents adjacent downstream boundaries needed to connect the open IR layer to later specialization stages without collapsing the open IR into one private runtime pipeline.
This directory defines intrinsic standardized primitive namespaces and primitive catalogs used by executable diagrams. It is the normative home of standardized primitive identities, ports, primitive-local metadata, and primitive-local behavior that belong to the intrinsic language surface.
This directory defines optional standardized capability families that extend the usable surface of FROG without redefining the canonical source structure of the language core and without redefining core execution semantics. It is the normative home of profile-owned primitive families and other optional capability contracts that should not be treated as intrinsic always-present language libraries.
This separation matters. Capabilities that depend on external ecosystems, foreign runtimes, platform services, ABIs, databases, network stacks, or similar assumptions SHOULD be standardized through profiles or external ecosystem layers rather than absorbed by default into the intrinsic library core.
In the current architectural baseline, the first concrete example of that separation is:
Libraries/Connectivity.md -> transition note only Profiles/Interop.md -> authoritative normative home of frog.connectivity.*
This directory defines the architecture and responsibilities of a FROG development environment. It explains how editing relates to the Program Model, serialized Expression, validation, IR derivation, execution preparation, execution observability, debugging, probes, watch views, snippets, and Express authoring.
The repository contains multiple normative and architectural documents. The map below summarizes the intended role of the Markdown documents in the current v0.1 baseline of the repository.
FROG/
├── Readme.md
│ -> repository landing page and global architectural entry point
├── CONTRIBUTING.md
│ -> contribution workflow, expectations, and cross-document coherence rules
├── CLA.md
│ -> contributor license agreement entry point and legal contribution notice
├── GOVERNANCE.md
│ -> repository governance, stewardship model, open-specification posture,
│ ecosystem participation, conformance direction, and branding boundary
│
├── Expression/
│ ├── Readme.md
│ │ -> architectural entry point for canonical source representation
│ ├── Metadata.md
│ │ -> descriptive program metadata and non-executable identification fields
│ ├── Type.md
│ │ -> canonical type-expression model used across the source format
│ ├── Interface.md
│ │ -> public typed inputs and outputs of a FROG
│ ├── Connector.md
│ │ -> graphical perimeter mapping of interface ports when reused as a node
│ ├── Diagram.md
│ │ -> authoritative executable graph as canonical source representation
│ ├── Front panel.md
│ │ -> optional front-panel composition and user-facing interaction surface
│ ├── Widget.md
│ │ -> widget object model, widget classes, properties, methods, events, and roles
│ ├── Widget interaction.md
│ │ -> diagram-side widget interaction paths and execution-facing widget access model
│ ├── Control structures.md
│ │ -> source-facing representation of canonical control structures
│ ├── State and cycles.md
│ │ -> source-facing representation of explicit local memory and cycle formation rules
│ ├── Icon.md
│ │ -> reusable-node icon representation
│ ├── IDE preferences.md
│ │ -> optional IDE-facing source metadata with no executable authority
│ └── Cache.md
│ -> optional non-authoritative cache content for tooling convenience
│
├── Language/
│ ├── Readme.md
│ │ -> architectural entry point for normative execution semantics
│ ├── Control structures.md
│ │ -> normative execution meaning of case, for_loop, and while_loop
│ ├── State and cycles.md
│ │ -> normative meaning of explicit local memory and valid feedback cycles
│ ├── Execution model.md
│ │ -> language-level execution-model core: validated program meaning,
│ │ live execution instance, source identity, activation, execution context,
│ │ semantic milestones, and committed source-level state
│ └── Execution control and observation boundaries.md
│ -> safe observation points, pause-consistent snapshots, safe debug stops,
│ and minimal completion / fault / abort boundary semantics
│
├── IR/
│ ├── Readme.md
│ │ -> architectural entry point for the IR layer and its ownership boundary
│ ├── Execution IR.md
│ │ -> open execution-facing IR model derived from validated program meaning
│ ├── Derivation rules.md
│ │ -> normative correspondence rules from validated program meaning to Execution IR
│ ├── Construction rules.md
│ │ -> normative rules for materially building open Execution IR
│ ├── Identity and Mapping.md
│ │ -> identity continuity and recoverable mapping across derivation and lowering boundaries
│ ├── Lowering.md
│ │ -> normative lowering boundary from open IR toward target-oriented executable forms
│ └── Backend contract.md
│ -> normative backend-facing contract for consumption of lowered execution forms
│
├── Libraries/
│ ├── Readme.md
│ │ -> architectural entry point for intrinsic standardized primitive families
│ ├── Core.md
│ │ -> foundational frog.core primitive library
│ ├── Math.md
│ │ -> frog.math numeric scalar operations beyond the minimal core
│ ├── Collections.md
│ │ -> frog.collections collection and array-oriented primitives
│ ├── Text.md
│ │ -> frog.text string and text-processing primitives
│ ├── IO.md
│ │ -> frog.io file, path, byte, and related I/O primitives
│ ├── Signal.md
│ │ -> frog.signal first-wave signal-processing primitives
│ ├── UI.md
│ │ -> frog.ui executable widget interaction primitives
│ └── Connectivity.md
│ -> transition note for frog.connectivity, redirecting normative ownership
│ to the Interop profile in Profiles/
│
├── Profiles/
│ ├── Readme.md
│ │ -> architectural entry point for optional standardized capability families
│ └── Interop.md
│ -> Interop profile specification for frog.connectivity.* and related
│ optional foreign-runtime / SQL interoperability capability
│
└── IDE/
├── Readme.md
│ -> architectural entry point for the FROG IDE and Program Model
├── Palette.md
│ -> palette model for surfacing primitives, structures, reusable nodes,
│ and guided authoring entries
├── Express.md
│ -> guided Express authoring model and normalization to canonical FROG content
├── Execution observability.md
│ -> source-aligned live execution observability contract for IDE tooling
├── Debugging.md
│ -> interactive debugging behavior built on source-aligned observability
├── Probes.md
│ -> live local inspection probes for values and selected execution state
├── Watch.md
│ -> persistent centralized watch-based inspection model
├── Snippet.md
│ -> image-backed snippet capture, transport, paste, and reuse workflows
└── FROG Snippet.md
-> legacy redirect document pointing to Snippet.md
This map is intentionally architectural rather than merely enumerative. Its purpose is to make repository ownership boundaries and recommended reading paths easier to understand.
Readers who are new to the repository should normally approach it in the following order:
Readme.md | v Expression/Readme.md | v Language/Readme.md | v IR/Readme.md | v Libraries/Readme.md | v Profiles/Readme.md | v IDE/Readme.md
This order mirrors the current architectural baseline:
- Expression defines the canonical saved source form,
- Language defines normative execution semantics for validated program meaning,
- IR defines the open execution-facing representation derived from that validated meaning,
- Libraries define the intrinsic standardized executable primitive vocabularies,
- Profiles define optional standardized capability families beyond the intrinsic core,
- IDE defines authoring, observability, debugging, and inspection responsibilities built on top of those foundations.
Readers who continue specifically into the IR layer SHOULD then follow:
IR/Readme.md | v Execution IR.md | v Derivation rules.md | v Construction rules.md | v Identity and Mapping.md | v Lowering.md | v Backend contract.md
That second path reflects the current published IR bundle: the open Execution IR core comes first, identity and mapping preserve attribution continuity, and downstream lowering and backend contracts remain explicitly downstream from the open IR core even though they are documented in the same directory.
The repository is intentionally split into distinct architectural layers:
- Expression — canonical source representation, source sections, and source serialization rules,
- Language — normative execution semantics for validated program meaning,
- IR — open execution-facing representations derived from validated program meaning,
- Libraries — intrinsic standardized primitive vocabularies and primitive-local behavior,
- Profiles — optional standardized capability families and profile-owned capability contracts,
- IDE — authoring architecture, editor-facing models, execution observability, debugging semantics, inspection workflows, snippets, and Express authoring.
This separation is deliberate. It prevents the language from being reduced to one editor, one runtime, one compiler, or one vendor implementation.
It also makes the repository suitable as the basis of an open standard: different actors may later build compatible IDEs, validators, runtimes, compilers, toolchains, ecosystem services, and profile-supporting implementations while still targeting the same language definition.
Expression/ -> canonical source form Language/ -> validated program meaning IR/ -> open execution-facing representation Libraries/ -> intrinsic standardized primitive vocabularies Profiles/ -> optional standardized capability families IDE/ -> authoring, observability, debugging, inspection
what is saved -> Expression/ what is true -> Language/ what is derived -> IR/ what exists -> Libraries/ and Profiles/ what is edited -> IDE/
Within that baseline, the IR/ directory already includes documents for identity and mapping, lowering, and backend-facing contracts.
Those documents remain architecturally downstream from the open Execution IR core, but they are already part of the published IR bundle.
Beyond the six top-level families listed above, later areas such as deployment, runtime profiles, or conformance-oriented execution profiles MAY be structured more explicitly over time. Those later areas are not yet closed top-level specification families in the same sense as the six layers listed above.
FROG programs should be understood across four distinct representation levels.
The FROG Expression is the serialized source representation stored in a .frog file.
It is the canonical source form of a FROG program.
A FROG is represented by a structured, human-readable JSON source file with the .frog extension.
That canonical source file is transparent, editable, portable, and version-control-friendly.
A canonical .frog source file MUST contain:
spec_version,metadata,interface,diagram.
It MAY additionally contain:
front_panel,connector,icon,ide,cache.
Optional sections MUST NOT redefine authoritative program semantics. The diagram remains the authoritative source-level execution structure. The public interface remains independent from the front panel. The front panel remains optional and non-authoritative for public interface definition.
The FROG Program Model is the canonical editable in-memory representation used by IDEs during authoring. It is reconstructed from the FROG Expression and maintained while the user edits the program.
It maintains coherent relationships between:
- interface declarations and
interface_input/interface_outputnodes, - front-panel widget declarations and
widget_value/widget_referencenodes, - structure nodes and their owned regions,
- semantic graph content and source-level layout information,
- authoring-facing insertion views and canonical source identities,
- Express presentation state and the canonical objects that an Express entry edits or materializes.
This Program Model is an IDE architectural concept. It is not the same thing as the raw serialized source file. It is also not, by itself, the normative execution-semantics layer of the language.
A source-derived FROG program must first be validated against the relevant language, primitive-library, and profile rules. That validated state is where normative execution meaning becomes a trustworthy basis for later derivation.
At this level, the repository defines:
- cross-cutting execution semantics,
- control-structure behavior,
- state and cycle validity,
- execution and observation boundaries,
- intrinsic primitive-local behavior,
- optional profile-owned capability behavior where applicable.
A validated FROG is not executed directly from raw source text. A conforming toolchain validates the source-derived program representation and then derives an open execution-facing representation suitable for execution preparation, analysis, normalization, optimization, lowering, or compilation.
That execution-facing level is the role of the IR layer. It is not the canonical source, not the IDE Program Model, and not one private runtime graph. It is the open execution-facing representation derived from validated program meaning.
Within the current published architecture, the open Execution IR core may then be accompanied by identity-preserving mapping, lowering, and backend-facing handoff boundaries as execution preparation progresses toward realization.
.frog source
|
v
Expression
|
v
Program Model
|
v
validated program meaning
|
v
open execution-facing representation
|
v
lowering / backend-facing handoff
A conforming FROG ecosystem should separate authoring, canonical source, validated program meaning, open execution-facing representation, and target-specific execution realization.
A FROG is not executed directly from raw source text. A toolchain edits a Program Model, serializes canonical source, validates program meaning against the relevant semantic, intrinsic-library, and profile rules, derives an open execution-facing representation, preserves recoverable attribution and mapping across that derivation, and only then proceeds toward lowering, backend preparation, compilation, or runtime realization.
FROG IDE
+-------------------------------+
| Diagram + Front Panel UI |
+---------------+---------------+
|
v
FROG Program Model
(editable in-memory model)
|
+-------------+-------------+
| |
| save / load | execute / validate
v v
🟩 OPEN SOURCE LAYER Validation against
🟩 FROG Expression +----------------------+
(.frog, canonical source) | Language/ |
| Libraries/ |
| Profiles/ |
+----------+-----------+
|
v
🟩 OPEN EXECUTION LAYER
🟩 FROG Execution IR
(derived, inspectable, source-attributed,
execution-facing, not backend-private)
|
v
Identity / Mapping preservation
|
v
Lowering / backend-facing handoff
|
v
Compiler(s) / Backend(s) / Runtime(s)
|
v
▶ Target execution instance
|
+------------------------+------------------------+
| |
v v
Source-aligned execution observability Runtime activity
(mapped back to meaningful FROG objects) on the active target
|
v
Debugging
(pause / resume / break / step)
|
+------+
| |
v v
Probes Watch
This architecture intentionally distinguishes two open specification-facing representation layers:
- FROG Expression — the canonical saved source artifact.
- FROG Execution IR — the open execution-facing representation derived from validated program meaning.
It also separates what remains normatively open and inspectable from what may remain implementation-specific:
- canonical source remains open, durable, and authoritative,
- execution IR remains open, inspectable, and specification-facing,
- identity and mapping remain recoverable where required for attribution and diagnostics,
- lowering, backend preparation, compiler internals, runtime scheduling, and target realization MAY vary across implementations.
Execution observability and debugging sit after live execution exists, but they are not defined as raw runtime internals. They are source-aligned views and controls that allow implementations to project live execution back onto meaningful FROG concepts such as graph activity, structures, regions, values, local memory, and selected execution objects.
what is saved -> Expression/ what is validated -> Language/ + Libraries/ + Profiles/ what is derived -> IR/ what is executed -> compiler / backend / runtime implementations what is observed -> IDE-facing source-aligned observability and debugging
This separation keeps FROG open as a language while still allowing multiple independent implementations to build different execution pipelines, runtimes, and target backends on top of the same specification.
During development, tools maintain the Program Model. Saving serializes that model into canonical source. Execution requests validate the relevant program content, derive an open execution-facing representation, and then pass that derived form into later execution-preparation or target-facing stages.
Interactive inspection and debugging are not performed directly on raw serialized source. They are performed on a live execution derived from validated program content and projected back onto source-meaningful objects.
Execution observability is the source-aligned live view that allows runtime activity to be mapped back to concepts such as:
- node activations,
- edge-level value availability,
- structure entry and region selection,
- loop iteration progression,
- local-memory state activity,
- pause-consistent execution snapshots.
Debugging is the interactive control layer built on top of that observability. It allows an IDE to inspect and guide execution through source-level concepts such as:
- execution highlighting,
- manual pause and resume,
- breakpoints,
- single-step controls,
- fault-directed source localization.
Probes are source-aligned live inspection tools built on top of execution observability and used together with debugging. They allow an IDE to inspect values or selected execution state associated with objects such as:
- edges,
- node ports,
- local-memory state,
- selected UI-related execution objects in stricter profiles.
Watch provides persistent centralized inspection of selected source-visible targets during or after live execution. Unlike probes, which are primarily local inspection objects, watches are intended to remain visible in a managed watch list or equivalent watch view.
In FROG, debugging and inspection are dataflow-first rather than line-oriented. They operate on observable graph activity, structures, sub-FROG scopes, value flow, local memory, and explicit UI-related execution objects rather than on a fictional sequential instruction list.
FROG programs are designed to remain source-level stable across multiple hardware classes. The language is not tied to one processor family, one operating system, one runtime architecture, or one vendor.
Representative target classes include:
- General-purpose CPUs — workstation, server, and industrial PC execution,
- Real-time targets — deterministic measurement and control systems,
- Embedded systems — ARM and edge-oriented devices,
- GPUs — accelerated compute targets,
- FPGAs — programmable-logic targets,
- Microcontrollers — constrained embedded execution,
- Industrial edge controllers — integrated vendor-specific control and acquisition platforms.
The programming model is intended to remain conceptually stable across such targets. What changes is the active execution profile, the validation or lowering strategy, the backend, and the available platform services.
More explicit target-profile standardization MAY be refined over time. At the current repository stage, target diversity is an architectural direction rather than a fully closed standalone profile taxonomy.
FROG aims to be more than a language that merely supports multiple targets. Its long-term goal is to provide an open industrial graphical programming standard that hardware and software ecosystems can build on without requiring a proprietary language boundary.
That means hardware vendors, runtime builders, industrial software platforms, embedded-system providers, and specialized toolchain developers should be able to support the same core language while preserving their own:
- runtime strategies,
- deployment models,
- validation constraints,
- hardware services,
- library stacks,
- target-specific optimization layers.
In practice, this may include:
- FROG-compatible runtimes,
- target-specific compilers and backends,
- driver-backed hardware libraries exposed as FROG nodes,
- deployment environments built around FROG execution,
- vendor-specific profiles or conformance targets.
FROG integrates validation and optimization into its architecture.
Base principles include:
- strict type validation,
- graph validation before execution,
- controlled execution and observation boundaries,
- explicit structure semantics,
- explicit local-memory semantics for valid feedback loops,
- deterministic execution guarantees where supported by the active profile.
Optimization occurs primarily in execution preparation, IR normalization, lowering, compilation, and backend stages:
- graph simplification,
- dead-node elimination,
- constant folding,
- memory optimization,
- parallel scheduling where valid,
- target-specific lowering,
- profile-aware specialization.
FROG is designed for interoperability at several levels:
- source interoperability — the canonical
.frogfile is readable, structured, and tool-independent, - editing interoperability — multiple IDEs may reconstruct equivalent Program Models,
- semantic interoperability — validated programs are interpreted against shared language, intrinsic-library, and profile specifications,
- IR interoperability — multiple toolchains may derive compatible open execution-facing representations,
- execution interoperability — multiple toolchains may target compatible artifacts and execution environments,
- ecosystem interoperability — the language remains separate from vendor lock-in.
FROG is also designed to integrate with external languages and platform APIs through stable interoperation mechanisms. In the current repository architecture, such environment-dependent capability families SHOULD be standardized through optional profiles rather than treated automatically as intrinsic standardized libraries.
At the current architectural baseline, the first concrete standardized interop capability family is owned by:
Profiles/Interop.mdRepresentative integration targets may include:
- C / C++,
- Rust,
- Python,
- .NET,
- other ABI-compatible environments.
External functions and platform services can be exposed as FROG nodes while preserving graph-level validation and explicit type behavior. This is also essential for hardware support, because drivers, SDKs, real-time services, FPGA toolflows, embedded platform stacks, and external software ecosystems can be integrated without collapsing the language into one closed ecosystem.
FROG explicitly separates:
- the language specification,
- the canonical source representation,
- the editable program model,
- validated program meaning,
- the open execution-facing representation,
- intrinsic standardized primitive vocabularies,
- optional standardized capability profiles,
- execution observability,
- interactive debugging semantics,
- live inspection through probes,
- persistent watch-based inspection,
- snippet-based authoring transport,
- compiler implementations,
- backend implementations,
- runtime implementations,
- development environments,
- hardware adaptation layers,
- deployment and orchestration layers.
At the modeling level, FROG also separates:
- language from IDE,
- source from IR,
- semantic truth from derived execution-facing representation,
- intrinsic libraries from optional profiles,
- IDE from runtime,
- runtime from hardware,
- public interface from front panel,
- diagram from connector,
- natural widget value flow from object-style widget interaction.
This enables:
- multiple IDE implementations,
- multiple validators,
- multiple IR-producing toolchains,
- multiple compilers,
- multiple backends,
- multiple runtimes,
- multiple profile-supporting ecosystems around the same core language,
- independent ecosystem evolution around a shared graphical standard.
The specification defines the language, not one product.
FROG is governed as an open specification. The repository is intended to remain readable, implementable, and usable by independent parties while preserving long-term architectural coherence.
The current governance model is steward-led. Graiphic is the initial steward of the FROG specification repository and is responsible for maintaining architectural coherence, reviewing proposed changes, and publishing authoritative repository revisions.
Open specification does not imply a single implementation model. Different actors may build open-source or proprietary IDEs, validators, runtimes, compilers, libraries, profiles, integrations, deployment systems, and related services around the FROG specification.
Openness of the specification does not automatically grant trademark rights or official compatibility claims. Names, logos, certification marks, and claims such as official, certified, endorsed, or FROG-certified MAY be governed by separate conformance, certification, and branding policies.
Over time, the governance model is intended to distinguish clearly between:
- implementing core FROG,
- implementing core FROG plus explicitly named profiles,
- claiming a conformant implementation under an applicable conformance policy,
- claiming certified or official compatibility status under an applicable certification or branding policy.
The intended ecosystem direction is that the specification remains open, while official certification, official branding, and equivalent steward-controlled compatibility claims MAY be governed separately. Commercial implementations seeking official certification or branding MAY be subject to paid verification or licensing policies, while non-commercial implementations MAY be verified free of charge or at minimal cost under applicable steward policies.
FROG is currently under active design, cleanup, and stabilization. The repository already contains substantial material across canonical source representation, language semantics, open execution-facing IR architecture, intrinsic standardized primitive libraries, optional profile architecture, and IDE architecture, but the overall specification is still converging toward a coherent v0.1 foundation.
Current repository direction includes:
- stabilizing the canonical source specification,
- stabilizing the separation between canonical source representation and normative execution semantics,
- stabilizing the separation between normative execution semantics and the open execution-facing IR layer,
- clarifying language semantics and execution behavior,
- maintaining a distinct open execution-facing IR layer without collapsing FROG into one private runtime pipeline,
- stabilizing recoverable identity and mapping across derivation and later specialization boundaries,
- clarifying lowering and backend-facing handoff boundaries without over-freezing private runtime internals,
- stabilizing the intrinsic library boundary,
- establishing optional profile families without collapsing them into the intrinsic core,
- keeping profile-owned capability families explicitly distinct from intrinsic libraries,
- defining IDE responsibilities without coupling the language to one implementation,
- defining source-aligned execution observability for live execution,
- defining dataflow-native debugging semantics for FROG IDEs,
- defining source-aligned live inspection through probes,
- defining persistent centralized watch-based inspection for FROG IDEs,
- defining image-backed snippet-based reusable authoring transport,
- defining guided Express authoring as an IDE convenience layer that normalizes to canonical FROG content.
At the same time, some broader execution-facing and deployment-facing areas remain architectural direction rather than fully closed top-level repository families. Topics such as deployment, runtime profiles, and conformance-oriented execution profiles MAY be refined further over time.
The long-term ambition is to establish a durable open graphical programming ecosystem that can scale from experimentation to deeply integrated industrial deployment.
Discussions, feedback, and contributions are welcome.
This project is licensed under the Apache License 2.0.
See LICENSE for details.
External contributions are governed through the repository contribution process and Contributor License Agreement requirements.
See CONTRIBUTING.md and CLA.md.
Repository stewardship, governance direction, and ecosystem positioning are described in GOVERNANCE.md.
FROG — Free Open Graphical Language
Open graphical dataflow programming, specified as a language rather than owned as a product.