🍳 Foodlangalpha

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, smart-appliance program, 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, smart-appliance program, Matter).

For OPC UA, smart-appliance program, 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