Wishlist for Tao 2

Syntax

Indentation sensitivity (so trailing pattern branches don't require \)
[ ... ] as kind parameter syntax, to reduce visual ambiguity (i.e: Result A E -> Result[A, E])
- TODO: Does this mean no more [T] list type syntax? (maybe it meants that already if having values as kinds?)
Unified def syntax (no more fn vs def)
Unified effect handler and pattern matching syntax (handling errors with effects should be as easy as with sum types)
Figure out intuitive, terse, and consistent do notation (or block syntax)
Unify tuple and record syntax? (A, B) vs (a: A, b: B). Is the latter unambiguous?
Better class member syntax

Values as kinds
Support type-level functions, covering the design space of Higher-Kinded Types, Higher-Ranked Types, and Generic Associated Types
- Values with a type containing a for (such as for T in T -> T, the identity function) must have opaque/unique types to guarantee monomorphisation (this also includes named types that hide a for inside them: perhaps this could be make explicit?)
- TODO: Does this extend to defs? Can you do def Natural : Type = Nat?
- TODO: This might be too far, types-as-values opens up many cans of worms
Numeric literal inference
Support 'peeling away' effects on effect handlers
Pattern-constrained types, i.e: Nat @ 0..10 with static analysis of terms as second typing pass
Multi-pass type system
- 1. Type inference (HM-style unification)
- 1. Effect inference (row-polymorphic grow-only subtyping)
- 1. Pattern inference (order-dependent flow typing)

Actually implement one. Rust-like seems the most natural, although it would be nice to simplify/flatten things in various ways, as well as sensibly handling method/function overrides or the like (to avoid Haskell's map problem)

Figure out an approach for implementing derivations
- Perhaps a const fn designated to a function that maps TypeAst -> MemberAst? See Haskell for interesting ideas