```
defmodule Tdd do
  @moduledoc """
  Ternary decision diagram, used for representing set-theoritic types, akin to cduce.
  There are 2 types of nodes: 
  - terminal nodes (true, false) 
  - variable nodes 

  variable nodes consist of:
  - the variable being tested 
  - yes: id of the node if the result of the test is true 
  - no: id of the node if the result of the test is false 
  - dc: id of the node if the result of the test is irrelevant for the current operation

  the TDD needs to be ordered and reduced (ROBDD)
  - 'ordered' if different variables appear in the same order on all paths from the root. 
  - 'reduced' if the following two rules have been applied to its graph:
    - Merge any isomorphic subgraphs.
    - Eliminate any node whose two children are isomorphic.

  Working notes:
  - structure of the ordered variables:
    Im thinking of structuring all possible types inside 1 TDD, in contrast to cduce, which uses a `desrc` structure that contains several TDDs (one for each domain, like ints, atoms, functions, etc.), and descr is a union between them.
    For this, I need to come up with a variable structure that'll be ordered. 
    My set types will need to represent types like: atoms, strings, ints, maps, tuples, functions, kinds, free polymorphic variables 
    Moreso, those types themselves consist of smaller subsets of types like:
    - int < 10 
    - int in [1, 2, 3]
    - string > "prefix_" 
    - atom == false
    - atom == false or atom == true or atom == nil
    - map == %{"id" => string} and %{string => any | nil}
    - polymorphic types ???
    - etc.
    Dont know how to represent them and make them ordered.
  - node cache:
    I suspect ids of nodes (TDDs) after reduction. This way a comparison between 2 types is just a pointer (id) check in the node cache. But not yet sure.
  - reduction rules: not sure how to approach them 

  """

  def node(elem, yes, no, dc = _dont_care) do
  end

  def sum(one, two) do
  end

  def intersect(one, two) do
  end

  def negate(one, two) do
  end
end
```
Please help me refine the theory for impementing set-theoritic types with this.
Lets focus on ordering of variables in the TDD

========================================================================================================================

Okay, this is a fascinating and ambitious goal! Building a single, ordered, reduced TDD for all Elixir/Erlang types is a significant challenge, especially with the rich structure of types like maps and functions. Let's break down the ordering of variables.

The core idea for ordering in a BDD/TDD is to have a **total global order** on all possible "questions" (predicates) you can ask about a value.

**High-Level Strategy for Ordering Variables**

1.  **Primary Type Discriminators First:** The most fundamental question is "What basic kind of thing is this?"
2.  **General Properties Next:** After knowing the primary type, ask about general properties (e.g., size, length).
3.  **Specific Value/Content Properties:** Then, delve into specific values or structural content.
4.  **Recursive Structure for Nested Types:** For types like tuples and maps, the predicates about their elements/values will effectively be recursive, but the ordering system must flatten this into a global order.

**Proposed Variable Ordering Scheme**

Let's define "variables" as unique identifiers for predicates. We need a way to sort these identifiers. A good way is to use tuples, where Elixir's natural tuple sorting provides the order.

**Category 0: Primary Type Discriminators**
These are the most fundamental. They will have the lowest sort order.
Order them alphabetically by the type name.
*   `v_is_atom = {0, :is_atom}`
*   `v_is_binary = {0, :is_binary}`
*   `v_is_float = {0, :is_float}`
*   `v_is_function = {0, :is_function}`
*   `v_is_integer = {0, :is_integer}`
*   `v_is_list = {0, :is_list}`
*   `v_is_map = {0, :is_map}`
*   `v_is_pid = {0, :is_pid}`
*   `v_is_port = {0, :is_port}`
*   `v_is_reference = {0, :is_reference}`
*   `v_is_string = {0, :is_string}` (*Note: Elixir strings are UTF-8 binaries. You might treat them as a subtype of binary or a distinct primary type in your model. For simplicity here, let's assume distinct for now, or you'd have predicates like `{0, :is_binary_utf8}` after `{0, :is_binary}`*)
*   `v_is_tuple = {0, :is_tuple}`

**Category 1: Atom-Specific Predicates**
If `is_atom` is true, what specific atom is it?
Order by the atom itself.
*   `v_atom_eq_false = {1, :value, false}`
*   `v_atom_eq_nil = {1, :value, nil}`
*   `v_atom_eq_true = {1, :value, true}`
*   `v_atom_eq_specific_A = {1, :value, :an_atom}` (e.g., `:an_atom` comes after `true`)
*   ... (all known/relevant atoms in your system, ordered canonically)

**Category 2: Integer-Specific Predicates**
If `is_integer` is true:
You need a canonical way to represent integer conditions.
*   Equality: `v_int_eq_N = {2, :eq, N}` (e.g., `{2, :eq, 0}`, `{2, :eq, 10}`)
    *   Order by N.
*   Less than: `v_int_lt_N = {2, :lt, N}` (e.g., `{2, :lt, 0}`, `{2, :lt, 10}`)
    *   Order by N.
*   Greater than: `v_int_gt_N = {2, :gt, N}` (e.g., `{2, :gt, 0}`, `{2, :gt, 10}`)
    *   Order by N.
*   Set membership for finite sets: `v_int_in_SET = {2, :in, Enum.sort(SET)}` (e.g. `{2, :in, [1,2,3]}`)
    *   Order by the canonical (sorted list) representation of SET.
    *   *This gets complex. Often, BDDs for integers use bit-level tests, but for set-theoretic types, range/specific value tests are more natural.* You might limit this to a predefined, finite set of "interesting" integer predicates.

**Category 3: String-Specific Predicates**
If `is_string` is true:
*   Equality: `v_string_eq_S = {3, :eq, S}` (e.g., `{3, :eq, "foo"}`)
    *   Order by S lexicographically.
*   Length: `v_string_len_eq_L = {3, :len_eq, L}`
    *   Order by L.
*   Prefix: `v_string_prefix_P = {3, :prefix, P}`
    *   Order by P lexicographically.
*   (Suffix, regex match, etc., can be added with consistent ordering rules)

**Category 4: Tuple-Specific Predicates**
If `is_tuple` is true:
1.  **Size first:**
    *   `v_tuple_size_eq_N = {4, :size, N}` (e.g., `{4, :size, 0}`, `{4, :size, 2}`)
        *   Order by N.
2.  **Element types (recursive structure in variable identifier):**
    For a tuple of a *given size*, we then check its elements. The predicate for an element will re-use the *entire variable ordering scheme* but scoped to that element.
    *   `v_tuple_elem_I_PRED = {4, :element, index_I, NESTED_PREDICATE_ID}`
        *   Order by `index_I` first.
        *   Then order by `NESTED_PREDICATE_ID` (which itself is one of these `{category, type, value}` tuples).
    *   Example: Is element 0 an atom? `v_el0_is_atom = {4, :element, 0, {0, :is_atom}}`
    *   Example: Is element 0 the atom `:foo`? `v_el0_is_foo = {4, :element, 0, {1, :value, :foo}}`
    *   Example: Is element 1 an integer? `v_el1_is_int = {4, :element, 1, {0, :is_integer}}`
    This ensures that all questions about element 0 come before element 1, and for each element, the standard hierarchy of questions is asked.

**Category 5: Map-Specific Predicates**
If `is_map` is true: This is the most complex.
1.  **Size (optional, but can be useful):**
    *   `v_map_size_eq_N = {5, :size, N}`
        *   Order by N.
2.  **Key Presence:**
    *   `v_map_has_key_K = {5, :has_key, K}` (e.g., `{5, :has_key, "id"}`, `{5, :has_key, :name}`)
        *   Order by K (canonically, e.g., strings before atoms, then lexicographically/atom-order).
3.  **Key Value Types (recursive structure):**
    For a *given key K* that is present:
    *   `v_map_key_K_value_PRED = {5, :key_value, K, NESTED_PREDICATE_ID}`
        *   Order by K (canonically).
        *   Then order by `NESTED_PREDICATE_ID`.
    *   Example: Does map have key `:id` and is its value a string?
        *   First variable: `v_map_has_id = {5, :has_key, :id}`
        *   If yes, next variable: `v_map_id_val_is_str = {5, :key_value, :id, {0, :is_string}}`
4.  **Predicates for "all other keys" / "pattern keys":**
    This is needed for types like `%{String.t() => integer()}`.
    *   `v_map_pattern_key_PRED_value_PRED = {5, :pattern_key, KEY_TYPE_PREDICATE_ID, VALUE_TYPE_PREDICATE_ID}`
    *   Example: For `%{String.t() => integer()}`:
        *   Key type predicate: `{0, :is_string}`
        *   Value type predicate for such keys: `{0, :is_integer}`
        *   Variable ID: `{5, :pattern_key, {0, :is_string}, {0, :is_integer}}`
    *   These pattern key predicates should likely be ordered *after* specific key predicates. The exact sorting of `KEY_TYPE_PREDICATE_ID` needs careful thought (e.g. `(0, :is_atom)` before `(0, :is_string)`).

**Category 6: List-Specific Predicates**
If `is_list` is true:
1.  **Is Empty:**
    *   `v_list_is_empty = {6, :is_empty}`
2.  **Head/Tail Structure (if not empty, recursive):**
    This mirrors how types like `nonempty_list(H, T)` are defined.
    *   `v_list_head_PRED = {6, :head, NESTED_PREDICATE_ID}`
    *   `v_list_tail_PRED = {6, :tail, NESTED_PREDICATE_ID}` (Note: `NESTED_PREDICATE_ID` for tail would again be list predicates like `{6, :is_empty}` or `{6, :head, ...}`)
    *   Example: Head is an atom: `{6, :head, {0, :is_atom}}`
    *   Example: Tail is an empty list: `{6, :tail, {6, :is_empty}}`
    *   All head predicates come before all tail predicates.

**Category 7: Function-Specific Predicates**
If `is_function` is true:
1.  **Arity:**
    *   `v_fun_arity_eq_A = {7, :arity, A}`
        *   Order by A.
2.  **Argument Types (very complex, may need simplification for TDDs):**
    *   `v_fun_arg_I_PRED = {7, :arg, index_I, NESTED_PREDICATE_ID}`
3.  **Return Type (also complex):**
    *   `v_fun_return_PRED = {7, :return, NESTED_PREDICATE_ID}`
    *   Function types are often represented by separate structures or simplified in TDDs due to their higher-order nature. Full function type checking within this TDD variable scheme would be extremely elaborate.

**Binary, Float, Pid, Port, Reference Predicates:**
These would get their own categories (e.g., 8, 9, 10...).
*   **Floats:** `{X, :is_float}` -> `{X, :eq, F}`, `{X, :lt, F}`, etc.
*   **Binaries:** `{Y, :is_binary}` -> `{Y, :size, S}`, `{Y, :matches_pattern, Pat}` (e.g. `<<h :: size(8), _ :: binary>>`)

**Polymorphic Variables (`alpha`, `beta`, etc.)**
Polymorphic variables are part of the *type language*, not properties of concrete values. A TDD represents a set of *concrete values*.
*   When you construct a TDD for a type like `list(alpha)`, where `alpha` is free, `alpha` essentially means `any`. So, for predicates concerning list elements, they would all go to their `dc` (don't care) branches, ultimately leading to `true`.
*   If `alpha` is bound (e.g., in `(alpha -> alpha) where alpha = integer`), you first resolve `alpha` to `integer` and then build the TDD for `(integer -> integer)`.
*   So, "free polymorphic variables" don't become TDD variables themselves. They influence which branches are taken during TDD construction for types containing them, often mapping to `any` or `dc` paths.

**"Kinds"**
The "kind" of a type (e.g., `Type.Atom`, `Type.Integer`) is meta-information. The TDD *represents* a type. The variables within the TDD are about properties of *values* that belong to that type. You wouldn't have a TDD variable `is_kind_atom?`. Instead, the TDD for the type `atom` would start with the `v_is_atom = {0, :is_atom}` variable.

**The `dc` (Don't Care) Branch**
The `dc` branch for a variable `v` in a node means that for the type being represented, the outcome of the test `v` is irrelevant to membership *given the path taken to reach this node*.
*   For type `any`, all variables would effectively go to `dc`, all leading to the `true_terminal`.
*   For type `integer`, the test `v_is_atom`:
    *   `yes` branch -> `false_terminal` (an atom is not an integer)
    *   `no` branch -> continues to test `v_is_integer`, etc.
    *   `dc` branch: This is the tricky part in TDDs for types. In some formulations, `dc(N)` is `yes(N) U no(N)`. If a type truly doesn't care about `v_is_atom` (e.g., `any`), then `yes`, `no`, and `dc` might all point to the same child representing `any` for subsequent tests.
    *   For `ROBDD` reduction with `dc`, if `yes_child == no_child == dc_child`, the node is redundant. If `yes_child == no_child`, the test `v` is locally irrelevant, and the node might be simplified (parent points to `yes_child`, and the `dc` path needs careful handling depending on the TDD algebra). Standard BDD reduction (if `yes_child == no_child`, eliminate node) assumes only two children. You'll need TDD-specific reduction rules.

**Summary of Ordering Logic:**
1.  Use tuples as variable identifiers: ` {category_num, predicate_type_atom, value_or_nested_id}`.
2.  Sort these tuples using Elixir's default tuple comparison. This establishes the global order.
3.  `category_num` provides the coarsest level of ordering.
4.  Within a category, `predicate_type_atom` provides the next level.
5.  Finally, `value_or_nested_id` provides the finest level, potentially recursively applying the same ordering logic for nested structures.

This structured approach to variable identifiers is crucial for the "ordered" property of your ROBDD. When implementing `apply` operations (union, intersect, negate), you'll always compare the variable IDs of the current nodes from the two TDDs and operate on the one that comes first in the global order.