🍳 Foodlang

Philosophy

Foodlang is built on a few firm commitments.

Foodlang does not invent syntax from scratch

The .food format uses KDL, a real document language. Foodlang defines a recipe schema on top of KDL.

The .food.yaml format follows Open Recipe Format-style structure so recipes can be stored and exchanged as structured data.

Foodlang's goal is to make recipes pleasant to write while still compiling to serious structured formats:

.food   = fun human authoring format
.food.yaml  = official ORF-compatible structured output
.food.json  = normalized compiler AST

Foodlang does not replace existing standards

Foodlang extends ORF-style YAML with an X-foodlang block. The base recipe stays readable by any ORF-aware tool. The extension is additive and ignorable.

Food is transformations

Normal recipes describe ingredients and human steps. Foodlang adds the missing layer — culinary transformations — that makes recipes executable:

milk:cold       -> milk:steamed + microfoam
coffee_grounds + hot_water -> espresso
dough:raw       -> bread:baked
onion:whole     -> onion:diced -> onion:sautéed

That transformation model is the bridge between human recipes and automation.

One source, many layers

Layer Standard / target Role
Human Cooklang Human-readable authoring / export
Web Schema.org Recipe JSON-LD Web publishing
Appliance OPC UA, Home Connect, MQTT, Matter Appliance targets (mappings)
Robot action graphs, PDDL, FOON, LTL Robot planning targets
Industrial ISA-88 / S88 Batch procedure inspiration

Be honest about fidelity

Foodlang refuses to overpromise. Every compiler target is labelled:

  • executable — a directly usable artifact (Schema.org, ORF).
  • mapping — exportable mapping data, not live device execution (OPC UA, MQTT, robot action graph, S88).
  • illustrative — educational / future-compatible (Cooklang, PDDL, FOON, Home Connect, Matter).

For OPC UA, Home Connect, Matter and vendor APIs, Foodlang produces mapping payloads, not real device execution. For PDDL, FOON, LTL and S88 it produces structured / illustrative representations, not a formal verification system.

Boring on purpose

Foodlang prefers clean, maintainable code over cleverness. The MVP exists to prove one architecture:

.food.yaml
  -> parse
  -> validate
  -> normalize
  -> compile to multiple targets