Handle co/contra/in-variance correctly.

[paulstansifer]

Currently Cell<Int> is a subtype of forall T . Cell<T>. That's okay. But also Cell<Sequence<Int>> is a subtype of Cell<forall T . Sequence<T>>. That's bad, because you can't actually put a generic sequence into a Cell that wants a sequence of Ints!

I think that a solution looks like this:

• Set the ExtraInfo for type comparison to std::cmd::Ordering (bonus: an easier way to reverse subtyping than swapping the main Ast and the context), and ... use it somehow. Do we need to look it up in every subtyping judgment? (a lot of them are LiteralLike, fortunately)
• Somehow communicate which type applications are which. But what about forall T. T<Int>? Maybe we want three different versions of forall and three different versions of <...>? Ugh!

So, this might be (part of the) reason why "normal" MLs don't have an explicit forall type (and, I guess, insist that A be defined if you write A<B>): that way you can infer co/contra/in-variance and not have to make a big deal about it. So maybe we should do the normal thing.

[paulstansifer]

Okay, the problem with forall T. T<Int> is that it doesn't have kind annotations (and we don't have a kind-checker yet (#3)). So I think we can get away with just modifying forall. So it's syntax time!

• forall co X contra Y in Z . ...
• forall +X -Y =Z . ...
• forall_co X . forall_contra Y . forall_inv Z . ...

...and, should the annotations be allowed to be omitted (meaning covariance)?