Tom Tuckit:

The ordering of the curry ingredients - turmeric vs garlic - should favor the most useful subsets of ingredients - for instance: a sauce might require garlic but not turmeric - that's one vote for a specific <= relationship.

...

Node 3:

That ordering rule turns partial application from an arbitrary syntax trick into a strict subset lattice.

If every stage in the currying pipeline represents a set of bound context ingredients I, then an ingredient A MUST precede ingredient B in the binding order if A can form a useful, standalone domain abstraction without B, but B without A is meaningless or invalid.

Garlic <= Turmeric  ===>  Garlic (General Substrate)  ⊂  Turmeric (Specialized Profile)

In software terms: if a Sauce (a broader family of abstractions) requires A but not B, while a Curry (a specialized downstream abstraction) requires both A and B, then A is foundational and B is a specialized refinement. Binding B first would destroy the ability to reuse the intermediate A-bound state for non-B domains.

Applied directly across our software hierarchy, this subtype/ingredient dependency lattice maps cleanly:

[Level 1: Dimensions]
      │
      ▼ (Garlic: spatial bounds alone unlock memory allocators, page buffers, raw bytes)
[Level 2: Storage]
      │
      ▼ (Onions: storage + element type unlocks 1D/2D/ND positional index algebra)
[Level 3: Sequence / Grid]
      │
      ▼ (Turmeric: sequence + character type unlocks general text, streams, regex)
[Level 4: String]
      │
      ▼ (Garam Masala: string + lexical rules unlocks Symbols, Identifiers, Paths)
[Level 5: Domain AST / Identifiers]

...

Tom Tuckit:

Now String doesn't have to extend (or implement) Sequence - it - waitaminit - my thoughts on porcelain are changing... String would take a curried [with Dimension and T element type] Sequence object in its constructor and - yes - become a porcelain dsl robot - in fact, it could be a curried abstract class with partial knowledge of its user's domain whose concrete subclasses can be created and destroyed like anything else. so we are using inheritance/composition hierarchies as currying, allowing for variations at each level.

...

Node 3:

In Git terms: Storage is the plumbing; Sequence is the porcelain.

Storage owns the actual physical reality—the cells, the contiguous memory blocks, the index bounds, the backing buffers, and the raw allocation.

Sequence<T> carries no competing state or parallel clock of its own. It is an immutable, zero-overhead domain lens wrapped around Storage<Sequence<T>, T>. It exposes a human-friendly, algebraic API (at, slice, concat, insertBefore, removeRange) that delegates directly down to total operations on Storage.

                       PORCELAIN (Domain DSL)
  Sequence<T>  ===>  algebraic math, slicing, concatenation, monads
                                 |
                          (passthrough)
                                 v
   Storage     ===>  raw cells, memory layout, bounds, physical allocations
                        PLUMBING (Substrate)

By binding parameter constraints progressively at each level of the inheritance and composition stack, each level acts as a partially applied function that bakes in specific domain invariants:

• Level 1: Storage<C, E> (Plumbing) — Binds raw cell layout & physical substrate
• Level 2: Sequence<E> (Algebra) — Curries Storage + Dimensions (pure positional algebra)
• Level 3: String (Curried Porcelain) — Curries Sequence<Char> + Cultural / Encoding semantics
• Level 4: Concrete Domain Strings (Specialized) — Curries String + Format / Validator rules (e.g., Identifier, Path)