Free Open Graphical Dataflow Programming Language
FROG is an open, hardware-agnostic graphical dataflow programming language designed to describe computation as executable graphs while remaining accessible, explicit, deterministic, inspectable, and scalable across heterogeneous execution targets.

Specification work initiated: 8 March 2026

What is FROG? • 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-driven sequences of 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 interface boundaries,
• front-panel widgets and interaction layers.

Execution emerges from data availability, structural rules, explicit control structures, 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. This separation provides a durable basis for multiple independent implementations and long-term industrial interoperability.

This repository exists to define the FROG specification itself. It is the place where the language and its supporting specification layers are written so that future actors may implement FROG-compatible IDEs, validators, runtimes, compilers, libraries, profiles, and related ecosystem components while targeting the same open standard.

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 not merely to make programming easier, and not merely to make execution more powerful. 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 instead of toward syntax-first representation.

Graphical dataflow programming has already demonstrated major advantages in many engineering domains:

• natural parallelism,
• deterministic execution,
• clear orchestration of behavior,
• strong correspondence between software structure and system behavior,
• high productivity for engineers, scientists, and domain experts.

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 vendors or toolchains 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 respecting one shared open language definition.

FROG is not an IDE.
FROG is not a single runtime.
FROG is not a vendor product.
FROG is a language specification with associated source, semantic, intrinsic-library, profile, and IDE-facing specification layers.

FROG follows a true dataflow execution model.

In traditional 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. This model enables:

• automatic parallelism where valid,
• clear dependency visibility,
• deterministic execution models,
• 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 two complementary layers:

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, and while_loop,
• public interface participation through interface_input and interface_output,
• front-panel value participation through widget_value,
• object-style widget interaction through widget_reference and frog.ui.* primitives,
• optional profile-owned capability usage where supported by the active implementation,
• explicit local memory and valid cycles.

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_reference together with frog.ui.property_read, frog.ui.property_write, and frog.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 programs
├── Libraries/                        Intrinsic standard 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 FROG programs. 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 intrinsic library 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 core 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 directory defines the architecture and responsibilities of a FROG development environment. It explains how editing relates to the Program Model, serialized Expression, validation, 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 role of every Markdown document currently present in 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, and future conformance / trademark 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 executable graph,
│   │      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
│
├── Libraries/
│   ├── Readme.md
│   │   -> architectural entry point for intrinsic standard 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
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 cross-cutting execution meaning for validated programs,
• 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.

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 programs,
• 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, 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.

At the current repository stage, this five-layer split is the main architectural baseline. Additional execution-facing layers such as IR, lowering, compilation, deployment, runtime profiles, or conformance-oriented execution profiles may be structured more explicitly over time, but they are not yet a separate fully closed top-level specification family in the same sense as Expression/, Language/, Libraries/, Profiles/, and IDE/.

FROG programs should be understood across three 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 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_output nodes,
• front-panel widget declarations and widget_value / widget_reference nodes,
• 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 and is central to the current IDE/ layer. 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 validated FROG is not executed directly from raw source text. A conforming toolchain is expected to validate the source-derived program representation and then derive an execution-oriented form suitable for execution, analysis, optimization, lowering, or compilation.

That execution-oriented level is an important part of the long-term architecture, but it is not yet a fully closed standalone top-level specification layer in the current repository. At the present stage, the repository defines the conceptual need for that layer and part of the language-level semantic foundations on which such a layer depends.

Accordingly, the current repository already stabilizes:

• the canonical source form,
• the editable Program Model as an IDE architectural concern,
• language-level execution semantics needed to interpret validated programs,
• intrinsic primitive vocabularies,
• optional profile-owned capability families,
• IDE-facing observability and debugging layers built on top of those semantics.

A conforming ecosystem may conceptually follow an architecture similar to the one below:

                 FROG IDE
        +---------------------------+
        | Diagram + Front Panel UI  |
        +-------------+-------------+
                      |
                      v
             FROG Program Model
         (editable in-memory model)
              /               \
             /                 \
            v                   v
   FROG Expression        Validation / Execution
(.frog source,              preparation pipeline
 human-readable JSON)              |
                                   v
                     Execution-oriented representation
                         (derived from validated content)
                                   |
                                   v
                      Compiler(s) / Backend(s) / Runtime(s)
                                   |
                                   v
                            Target execution
                                   |
                  +----------------+----------------+
                  |                                 |
                  v                                 v
       Execution observability             Runtime activity
      (source-aligned live view)          on the active target
                  |
                  v
               Debugging
      (pause / resume / break / step)
                  |
        +---------+---------+
        |                   |
        v                   v
      Probes              Watch
 (local inspection)   (persistent inspection)

During development, tools maintain the Program Model. Saving serializes that model into canonical source. Execution requests validate the relevant program content and derive an execution-oriented form that is then consumed by execution-facing systems.

This architecture enforces a clean separation between:

• authoring,
• source serialization,
• editable in-memory representation,
• execution preparation,
• execution-oriented derivation,
• live execution observability,
• interactive debugging control,
• live inspection through probes,
• persistent inspection through watch views,
• compilation and backend processing,
• runtime execution.

The current repository defines this architecture unevenly by design: some layers are already documented in detail, while others remain architectural direction awaiting more explicit future specification work.

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-facing preparation, 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 .frog file 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,
• execution interoperability — multiple toolchains may derive compatible execution-facing representations and target artifacts,
• ecosystem interoperability — the language remains separate from vendor lock-in.

FROG is also designed to integrate with external languages and external platform APIs through stable interoperation mechanisms. In the current repository architecture, such environment-dependent capability families are expected to be standardized through optional profiles rather than treated automatically as intrinsic standard libraries.

Representative 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,
• intrinsic primitive vocabularies,
• optional standardized capability profiles,
• execution-oriented derivation,
• 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,
• 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 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, or endorsed may be governed by separate policies when such policies are published.

This repository therefore separates:

• the open normative specification,
• the governance and stewardship model,
• the contribution process and CLA,
• any future conformance, certification, trademark, or ecosystem business policies.

FROG is currently under active design, cleanup, and stabilization. The repository already contains substantial material across canonical source representation, language semantics, intrinsic standard 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,
• clarifying language semantics and execution behavior,
• stabilizing the intrinsic library boundary,
• establishing optional profile families without collapsing them into the intrinsic core,
• 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 layers remain architectural direction rather than fully closed repository families. Topics such as more explicit IR structuring, lowering, compilation, deployment profiles, runtime-facing specification layers, 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.