Skip to content

Readme.md

Latest commit

 

History

History
228 lines (172 loc) · 5.71 KB

Readme.md

File metadata and controls

228 lines (172 loc) · 5.71 KB

FROG logo

FROG Valid Structural Conformance Cases

Positive structural-source acceptance cases for canonical .frog programs
FROG — Free Open Graphical Language

Contents

1. Overview

This subtree groups valid structural conformance cases for canonical .frog source.

The cases in this subtree are intentionally narrow. They verify that a source artifact is:

  • loadable as canonical JSON source,
  • structurally valid as canonical .frog source under the published Expression/ ownership boundary,
  • accepted before later semantic, IR, lowering, backend, or runtime-specific questions are considered.

These cases are therefore about source-shape truth, not full language closure.

2. Purpose of this Subtree

This subtree exists to make focused structural acceptance rules public and testable without overloading the historical top-level Conformance/valid/ block.

It is appropriate when:

  • the relevant law is already published in Expression/,
  • the expected result is structural acceptance,
  • the case does not need to prove a richer semantic, IR, or executable property.

Conceptually: 

loadable source
+
structurally valid canonical shape
    ->
accepted here

3. Ownership Boundary

This subtree does not invent new rules.

Its cases map back to published source ownership, especially:

  • Expression/Readme.md,
  • Expression/Schema.md,
  • Expression/schema/frog.schema.json,
  • the relevant section-owning documents such as Front panel.md and Widget.md.

These cases therefore test:

  • source shape,
  • required-versus-optional section discipline,
  • selected section-local structural rules.

They do not own semantic meaning, IR law, or runtime truth.

4. How to Read These Cases

Each case directory SHOULD contain:

  • a Readme.md that explains the boundary being tested,
  • a case.frog artifact that provides the concrete canonical-source input.

The case.frog file is the authoritative concrete input. The local README explains why that input must be accepted structurally.

5. Published Cases

The initial published structural valid cases are:

  • 01_front_panel_canvas_widgets_and_ui_libraries
  • 02_front_panel_recursive_children_shape_is_valid

Together, they expose two useful positive source-shape truths:

  • the conservative published front_panel object shape is accepted,
  • recursive children shape is accepted structurally when serialized correctly.

6. Expected Outcomes

The expected outcome class for this subtree is: 

Expected loadability: loadable
Expected structural validity: valid
Expected meaning: established
Expected downstream progress: permitted to proceed according to later published rules

This does not mean a case in this subtree proves full semantic richness. It only means structural acceptance must occur at the correct stage.

7. What These Cases Do Not Prove

Cases in this subtree do not automatically prove:

  • widget class legality,
  • role/class compatibility,
  • type legality beyond source-shape acceptance,
  • diagram-side widget interaction legality,
  • IR construction correctness,
  • runtime behavior.

Those belong to later validation layers or other conformance families.

8. Relation with the Rest of Conformance

This subtree should be read as structured growth under the broader positive conformance surface: 

Conformance/valid/
    ├── historical top-level anchors
    ├── compiler/
    ├── executable/
    └── structural/

It does not replace the top-level valid anchors. It provides a clearer home for focused structural-source growth.

9. Summary

This subtree groups positive structural conformance cases for canonical source.

It exists to make source-shape acceptance explicit, testable, and attributable without confusing:

  • structural validity,
  • semantic acceptance,
  • IR correctness,
  • runtime truth.