type variables

[Bruce Carneal]

Recent discussions in other threads, and at beerconf, have 
prompted thoughts about type variables.  Below is a snapshot of 
my thinking on the topic. Corrections/simplifications/additions 
are solicited, particularly from those who know more about this 
than I do.  (if you're in doubt, answer in the affirmative)


Type variables carry with them quite a few things.  Most 
understandably they carry structural information, how the builtin 
types and compile-time constants were combined to form this type.

They can also carry naming information: phobos Typedef, struct 
field names, method names, aliasings, scope information as to 
where/how the type was formed, ...

Current dlang type 'variables' are created in a strictly 
functional style.  IOW, they come from declarative syntax, CTFE 
constants, and possibly recursive application of templates.

Pure functional programming is great wrt correctness, it's 
working today, but it's not-so-great when it comes to 
readability/maintainability.  For starters, composition is a 
challenge.  Unwinding recursions in your head is another 
challenge.  Debugging is another challenge.

Additionally, any template recursions extend the type names in a 
very ugly way.  Yes, the extension will give you a unique 
(unintelligible ginormous) name but that's about it.  Seems that 
we should be able to get a unique mangle without the garbage, 
something that a human could read and have a prayer of 
understanding while the universe is still warm.

So, what if we had mutable type variables that were 
canonicalized/frozen/vetted by the compiler?

Mutations might initially be restricted to those that could be 
independently checked for correctness.  This could get us off the 
ground wrt composition and avoid a full (re)check when a 
correct/concrete type is needed.

Structural equivalence could be factored out from name 
equivalence, both for speed and functionality.

Type functions should become both more powerful and more readable.

I believe as Andrei apparently does, that we're still in the 
early phases of meta programming, that we need more not less meta 
capability, and that rebasing the compiler to, itself, be both 
simpler and more capable in the meta realm will pay big ongoing 
dividends.

As noted above, destruction requested.