From f2d5fd2292f412d11b8e3fff526edafbd7b84864 Mon Sep 17 00:00:00 2001 From: Youssef Menjour <71812679+Ymenjour@users.noreply.github.com> Date: Sat, 23 May 2026 22:30:41 +0200 Subject: [PATCH 1/2] docs: clarify format-first positioning --- Readme.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/Readme.md b/Readme.md index f9e3c1a..cc90d35 100644 --- a/Readme.md +++ b/Readme.md @@ -109,6 +109,16 @@ opens the language layer so multiple tools, runtimes, compilers, and deployment models can share durable public meaning.
+
+FROG is therefore not an IDE-first platform. A FROG IDE is a tool that edits,
+validates, observes, and projects a FROG program; it is not the owner of the
+language. The durable asset is the canonical .frog source, the
+validated meaning, the open FIR, and the explicit downstream contracts. This
+means IDEs, runtimes, compilers, UI hosts, and hardware backends can evolve or
+be replaced without making existing FROG programs dependent on one monolithic
+product stack.
+
+
+
+FROG is intentionally designed as a format-first and pipeline-first graphical
+language foundation. The IDE is not the language. The runtime is not the
+language. The compiler is not the language. The durable public contract is the
+progression from canonical .frog source to validated meaning,
+open FIR, lowering boundaries, backend contracts, and explicit runtime or
+compiler consumption.
+
+This distinction protects the long-term maintainability of FROG programs. +A graphical editor may evolve, be replaced, or disappear without becoming the +owner of the program. A runtime may be versioned, specialized, or replaced +without redefining the source language. A compiler path may change without +turning the compiler into the semantic truth of the ecosystem. +
+ ++The durable asset is therefore not one IDE project file or one private execution +stack. The durable asset is the public chain of artifacts and contracts: +
+ +.frog canonical source
+ -> structural validation
+ -> semantic validation
+ -> validated program meaning
+ -> open FIR
+ -> lowering boundary
+ -> backend contract
+ -> runtime-family or compiler-family consumption
+
+
++This avoids the structural risk of graphical programming platforms where the +editor, saved format, execution model, runtime, compiler, and hardware ecosystem +become inseparable. In FROG, an IDE may provide authoring, debugging, +observability, front-panel editing, validation feedback, and deployment tooling, +but it consumes specification-owned artifacts rather than owning the language. +
+ ++The same rule applies downstream. A runtime host can provide live execution, +state management, probes, watches, UI hosting, diagnostics, and operational +orchestration. A compiler path can produce native or optimized artifacts. Both +paths remain consumers of explicit contracts. Neither path becomes the permanent +identity of FROG. +
+ ++For industrial users, this is the practical consequence: existing FROG programs +should remain maintainable over time because their meaning is anchored in open +source artifacts, explicit validation rules, open execution-facing IR posture, +explicit downstream handoff contracts, and conformance expectations rather than +in the continued existence of one monolithic product stack. +
+ +
+ FROG — Free Open Graphical Language
+ Open graphical dataflow programming, specified as a language rather than owned as a product.
+