Let's add these to the table:
```text
[P, P] => P
[P, (O N)] => (O N)
[P, (I N)] => (I N)
[(O N), P] => (O N)
[(I N), P] => (I N)
// New:
[(O M), (O N)] => (O (# M N))
[(I M), (O N)] => (I (# M N))
[(O M), (I N)] => (I (# M N))
[(I M), (I N)] => (O (# (# I M) N))
```
Here's something new: the `(# ...)` notation. This tells the macro, "hey, we wanna recurse." It's really shorthand
for a slightly more complex piece of notation, but they both have one thing in common - *when type_operators processes
the `(# ...)` notation, it uses it to calculate trait bounds.* This is because your type operator won't compile unless
it's absolutely certain that `(# M N)` will actually have a defined result. At an even higher level, this is the reason
I wish Rust had "closed type families" - if `P`, `I`, and `O` were in a closed type family `Nat`, Rust could check at compile-time
and be absolutely sure that `(# M N)` existed for all `M` and `N` that are in the `Nat` family.

So then. Let's load this into an invocation of `type_operators` to see how it looks like. It's pretty close to the table,
but with a couple additions (I'm leaving out `Undefined` for now because it's not yet relevant):

```rust
type_operators! {
[A, B, C, D, E]

concrete Nat => usize {
P => 0,
I(N: Nat = P) => 1 + 2 * N,
O(N: Nat = P) => 2 * N,
}

(Sum) Adding(Nat, Nat): Nat {
[P, P] => P
forall (N: Nat) {
[(O N), P] => (O N)
[(I N), P] => (I N)
[P, (O N)] => (O N)
[P, (I N)] => (I N)
}
forall (N: Nat, M: Nat) {
[(O M), (O N)] => (O (# M N))
[(I M), (O N)] => (I (# M N))
[(O M), (I N)] => (I (# M N))
[(I M), (I N)] => (O (# (# M N) I))
}
}
}
```

There are several things to note. First, the definition `(Sum) Adding(Nat, Nat): Nat`. This says,
"this type operator takes two `Nat`s as input and outputs a `Nat`." Since addition is implemented
as a recursive trait under the hood, this means we get a trait definition of the form:

```rust
pub trait Adding: Nat {
type Output: Nat;
}
```

The `(Sum)` bit declares a nice, convenient alias for us, so that instead of typing `>::Output`
to get the sum of two numbers, we can instead type `Sum`. Much neater.

Second, the "quantifier" sections (the parts with `forall`) avoid Rust complaining about "undeclared type variables." In any given
generic `impl`, we have to worry about declaring what type variables/generic type parameters we can use in
that `impl`. The `forall` bit modifies the prelude of the `impl`. For example, `forall (N: Nat)` causes all the
`impl`s inside its little block to be declared as `impl ...` instead of `impl ...`, so that we can use
`N` as a variable inside those expressions.

That just about wraps up our short introduction. To finish, here are the rest of the notations specific to our
little LISP-y dialect, all of which can only be used on the right-hand side of a rule in the DSL:

- `(@TypeOperator ...)` invokes another type operator (can be the original caller!) and generates the proper trait bounds.
- `(% ...)` is like `(# ...)`, but does not generate any trait bounds.
- `(& where () () ...)` allows for the definition of custom `where` clauses for a given
`impl`. It can appear anywhere in the right-hand side of a rule in the DSL, but in general should probably always be
written at the top-level for consistency.

In addition, it is possible to use attributes such as `#[derive(...)]` or `#[cfg(...)]` on `data` and `concrete` definitions
as well as individual elements inside them. In addition, attributes can be added to the `impl`s for rules. For example:

```rust
type_operators! {
[A, B, C, D, E]

data Nat: Default + Debug where #[derive(Default, Debug)] {
P,
I(Nat = P),
O(Nat = P),
#[cfg(features = "specialization")]
Error,
#[cfg(features = "specialization")]
DEFAULT,
}

(Sum) Adding(Nat, Nat): Nat {
[P, P] => P
forall (N: Nat) {
[(O N), P] => (O N)
[(I N), P] => (I N)
[P, (O N)] => (O N)
[P, (I N)] => (I N)
}
forall (N: Nat, M: Nat) {
[(O M), (O N)] => (O (# M N))
[(I M), (O N)] => (I (# M N))
[(O M), (I N)] => (I (# M N))
[(I M), (I N)] => (O (# (# M N) I))

#[cfg(features = "specialization")] {
{M, N} => Error
}
}
}
}
```

Note the block `#[cfg(features = "specialization")] { ... }`. This tells `type_operators!` to add the attribute
`#[cfg(features = "specialization")]` to every `impl` declared inside. It's also worth noting that adding derives
to every single statement inside a `concrete` or `data` declaration can be done as shown above with a `where`
clause-like structure - the reason we have to do this is because if we were allowed to define it the intuitive
way, there would be no easy way to extract doc comments on the group trait (thanks to macro parsing ambiguities.)

Current bugs/improvements to be made:
- Bounds in type operators are currently restricted to identifiers only - they should be augmented with a LISP-like
dialect similar to the rest of the macro system.

If questions are had, I may be found either at my email (which is listed on GitHub) or on the `#rust` IRC, where I go by
the nick `sleffy`.

## License

Licensed under either of

* Apache License, Version 2.0, ([LICENSE-APACHE](LICENSE-APACHE) or http://www.apache.org/licenses/LICENSE-2.0)
* MIT license ([LICENSE-MIT](LICENSE-MIT) or http://opensource.org/licenses/MIT)

at your option.

### Contribution