+
+A FROG program starts from canonical .frog source. The
+.frog file owns the program-level source: metadata, public
+interface, executable diagram, optional front panel, widget instances, and
+diagram/widget bindings.
+
+When a front panel is present, canonical source may reference widget classes,
+widget packages, or realization choices. .wfrog packages publish
+widget-oriented package content such as reusable widget law, compositions,
+realization metadata, bounded behavior surfaces, host-binding metadata, and
+visual resources. SVG assets may participate as visual realization resources.
+None of those artifacts replaces .frog as the canonical program
+source, and none of them becomes hidden language semantics.
+
.frog source
+ -> loadability
+ -> structural validation
+ -> semantic validation
+ -> validated program meaning
+ -> FIR / Execution IR
+ -> lowering
+ -> backend contract
+ -> runtime-family and/or compiler-family consumption+For compiler-family paths such as LLVM, the lowered form may be consumed to +produce an LLVM-oriented module, native proof, or native loadable artifact. +LLVM remains a downstream compiler-family consumer; it does not define FROG +semantics and does not replace the runtime boundary. +
+ ++For runtime-family paths, the runtime consumes explicit contracts and published +artifacts. It may instantiate a front panel through a host-specific UI layer, +bind widget values or widget references to execution-facing units, load or call +compiled artifacts when applicable, execute the dataflow unit, and project +results, diagnostics, and observability back to source-meaningful objects. +
+ +| Artifact or layer | +Pipeline role | +
|---|---|
.frog |
+ Canonical program source. | +
.wfrog |
+ Widget/package publication or realization metadata. | +
| SVG/assets | +Visual realization resources. | +
| FIR / Execution IR | +Open execution-facing representation derived from validated meaning. | +
| Lowering | +Target, backend, runtime, or deployment specialization. | +
| Backend contract | +Explicit downstream handoff. | +
| LLVM | +One possible compiler-family consumer and native proof path. | +
| Runtime | +Execution and orchestration consumer of explicit contracts and artifacts. | +
| Host UI | +Rendering and interaction surface; replaceable across host families. | +
+The practical reference-corridor details are documented in +Reference Pipeline. +A concrete UI/runtime/LLVM-oriented example is documented in +Example 05 — Bounded UI Accumulator. +
+ +@@ -254,6 +355,7 @@ published-state and maturity notes that used to live here.
+This section describes the current reference corridor as a non-normative +implementation-facing shape. It explains how the published artifacts are wired +together for the bounded public reference runtime closure. It does not define +the FROG language, widget law, runtime law, LLVM law, or future production +implementation strategy. +
+ +main.frog
+ -> loadability
+ -> structural validation
+ -> semantic validation
+ -> main.fir.json
+ -> main.lowering.json
+ -> backend contract
+ -> runtime acceptance
+ -> LLVM-oriented module / native proof where applicable
+ -> runtime orchestration
+ -> host UI / front-panel update where applicable+The current UI and native-proof corridor has two visible branches that meet at +the runtime boundary. +
+ ++The diagram and computation branch is: +
+ +.frog diagram
+ -> loadability / structural validation
+ -> semantic validation
+ -> FIR / Execution IR
+ -> lowering
+ -> backend contract
+ -> LLVM-oriented module or native loadable artifact where applicable
+ -> runtime call/load boundary+The front-panel and widget branch is: +
+ +.frog front_panel
+ -> widget instances and diagram/widget bindings
+ -> .wfrog packages or realization packages
+ -> SVG/assets and realization resources
+ -> host UI+The runtime joins those branches by consuming explicit published artifacts +rather than by becoming the owner of language semantics. In the current +reference corridor, runtime-family consumers may: +
+ +widget_value and widget_reference surfaces to execution-facing values, properties, or calls,+LLVM remains one compiler-family proof path in this repository. It may consume +lowered material to produce an LLVM-oriented module or native proof artifact, +but it does not replace FIR, does not define FROG semantics, and does not make +the runtime LLVM-specific. +
+ +python Implementations/Reference/Pipeline/check_examples01_10_full.py
+
+
+ Concrete source, FIR, lowering, runtime, widget, and LLVM-oriented proof corridor for Example 05
+ FROG — Free Open Graphical Language
+
+This page explains how Examples/05_bounded_ui_accumulator runs through the current public reference corridor.
+It is a concrete companion to Example 05 — Bounded UI Accumulator.
+
+The page is descriptive and non-normative. It does not make LLVM part of FROG semantics, does not define a production runtime, and does not turn one hosted UI into the FROG language runtime identity. +
+ +Examples/05_bounded_ui_accumulator/main.frog
+ -> loadability
+ -> structural validation
+ -> semantic validation
+ -> Examples/05_bounded_ui_accumulator/main.fir.json
+ -> Examples/05_bounded_ui_accumulator/main.lowering.json
+ -> Implementations/Reference/ContractEmitter/examples/05_bounded_ui_accumulator.reference_host_runtime_ui_binding.contract.json
+ -> Implementations/Reference/Runtime/acceptance/example05_runtime_family.acceptance.json
+ -> Implementations/Reference/LLVM/examples/05_bounded_ui_accumulator/module.ll
+ -> Implementations/Reference/LLVM/examples/05_bounded_ui_accumulator/kernel.ll
+ -> Implementations/Reference/LLVM/examples/05_bounded_ui_accumulator/native_kernel_manifest.json
+ -> runtime bridge and hosted front-panel snapshotmain.frog diagram
+ -> validated program meaning
+ -> FIR / Execution IR
+ -> lowering
+ -> backend contract
+ -> LLVM-oriented module / native proof where applicable
+ -> runtime call boundary+The diagram branch owns the executable dataflow path. In this example, the bounded accumulator computes the result from the public input and explicit stateful iteration shape. +
+ +main.frog front_panel
+ -> ui/accumulator_panel.wfrog
+ -> Libraries/Realizations/Default/assets/numeric/templates/numeric_rectangular.svg
+ -> hosted numeric control and indicator realization
+ -> runtime widget bindings
+The front-panel branch owns the visible widget layout and realization-facing path. The .wfrog package and SVG asset support realization; they do not replace .frog as the program source and do not define hidden language semantics.
+
+The runtime is the orchestration consumer at the point where the two branches meet. +For this example, the runtime-family corridor may: +
+ +.frog front-panel instances,.wfrog realization package and numeric SVG realization asset,ctrl_input.value to the execution input,ind_result.value,+In a hosted Run/Execute loop, the host samples the input-side widget value, the runtime executes the bounded dataflow unit, and the result is projected back into the output-side widget and published snapshot. +
+ +.frog remains the canonical program source..wfrog remains the widget/front-panel package and realization publication path.
+ 
+
+ Clarifying the role of FIR when front-panel widgets, runtime orchestration, and compiler-family artifacts meet
+ FROG — Free Open Graphical Language
+
+This companion note clarifies how FIR participates in a practical FROG execution corridor that includes a front panel, widget bindings, runtime orchestration, and optional compiler-family artifacts such as LLVM-oriented native proof material. +
+ ++It complements IR/Readme.md, IR/Lowering.md, and IR/Backend contract.md without replacing their ownership. +
+ ++FIR is the open execution-facing representation derived from validated program meaning. It is not authored directly, and it is not a runtime-private graph, compiler-private graph, LLVM IR file, widget package, visual asset, or host UI object table. +
+ +canonical .frog source
+ -> loadability
+ -> structural validation
+ -> semantic validation
+ -> validated program meaning
+ -> FIR / Execution IR
+ -> lowering
+ -> backend contract
+ -> runtime-family and/or compiler-family consumption+In hybrid UI/compiler execution, FIR may preserve execution-relevant consequences of validated widget and interface meaning, including: +
+ +widget_value participation where a widget's primary value enters or receives execution data,widget_reference participation where object-style interaction targets properties, methods, events, or parts,frog.ui.property_read, frog.ui.property_write, or frog.ui.method_invoke.+This preservation exists so later lowering, backend contracts, runtime binding, diagnostics, probes, watches, and source-aligned observability can remain traceable. +
+ ++FIR must not absorb or redefine ownership of: +
+ +.frog source structure,.wfrog package definition,+A practical hosted execution may contain two branches: +
+ +diagram/computation branch:
+.frog diagram
+ -> semantic validation
+ -> FIR
+ -> lowering
+ -> backend contract
+ -> LLVM-oriented artifact or other backend-family artifact where applicable
+
+front-panel/widget branch:
+.frog front_panel
+ -> widget instances and bindings
+ -> .wfrog packages or realization packages
+ -> SVG/assets or other realization resources
+ -> host UI+FIR sits on the execution-facing branch after validated meaning. It may carry enough widget-related identity and mapping to allow the runtime to bind values and object-style accesses, but it does not own the front-panel realization itself. +
+ ++A runtime may consume FIR-derived contracts, manifests, and artifacts. A compiler-family path such as LLVM may consume lowered material to produce a native proof or loadable artifact. Neither the runtime nor LLVM becomes the language owner. +
+ +| Layer | +Correct role | +
|---|---|
| FIR | +Open execution-facing representation derived from validated meaning. | +
| Lowering | +Specialization toward target, backend, runtime, provider, or deployment concerns. | +
| Backend contract | +Explicit handoff to downstream consumers. | +
| LLVM | +One possible compiler-family consumer and native proof path. | +
| Runtime | +Execution and orchestration consumer of explicit contracts and artifacts. | +
| Host UI | +Rendering and interaction surface, replaceable by host family. | +
.frog..wfrog.
+
+
+ How .wfrog packages participate in hosted front-panel realization
+ FROG — Free Open Graphical Language
+
+This companion note clarifies how widget packages participate when a FROG front panel is hosted by a runtime or UI host. +It complements FROG Widget Package (.wfrog). +
+ +.frog is the canonical program source..wfrog publishes widget package and realization-facing metadata.
+A .frog source may identify widget classes, widget package identities, or realization choices. A host may then resolve compatible .wfrog packages and related assets when a front panel needs to be rendered or interacted with.
+
.frog front_panel
+ -> widget instances, layout, initial values, and diagram/widget bindings
+ -> referenced widget classes or package identities
+ -> compatible .wfrog package
+ -> SVG/assets or other realization resources
+ -> host UI
+ -> runtime widget bindings+The host/runtime consumption role may include package resolution, asset loading, part mapping, value binding, property binding, event routing, capability checks, and diagnostic reporting. +
+ +.wfrog package does not replace the canonical .frog program source.
+In a hosted example, the front-panel branch and execution branch meet through runtime bindings.
+The .wfrog package helps the host realize visible widgets, while FIR, lowering, backend contracts, manifests, and runtime-family artifacts carry the execution-facing path.
+