[Grace-core] Type Parameters and parametric type

[Lex Spoon]

Quite a few interesting topics being raised! A few random comments,
hopefully helping some of those topics converge:

1. The parametric typing idea is deep and deserves careful attention.
You really can think of entities taking both type and value
parameters, even in designs like Java where the type parameters are
all erased at compile time.

2. To contrast, the object-oriented version of generics, where you
have type *members* instead of type *parameters*, I don't think has
worked out spectacularly well. Note that Java went with type
*parameters*.

3. As a pragmatic matter, a lot of time can go away working on type
fundamentals. Granted, I have a hard time resisting it, myself!

4. While it's true that top/bottom/super/sub and so on are just
conventions, I cannot recall seeing any convention used except that
superclasses are supertypes and are "higher" in the lattice. Thus, the
*join* of two object types is the one that has all methods common to
both of them. It's intuitively weird because with object types, when
you go up the hierarchy, you have fewer methods available. As extra
weirdness, actual implementations usually defy the theory in the case
of null and bottom; from a theory point of view, null and bottom
should actually support all methods, but does any implementation
actually work that way?

5. If-then-else is easy if you take the right perspective. There's no
reason to find a *least* upper bound; rather, you need to find *an*
upper bound. If you insist on a least upper bound, you can really go
traipsing into the daisy field. Corollary: many discussions of "type
lattices" are not about actual lattices. For example, Java types have
neither lubs nor glbs.

6. Target typing helps the above problem. If a programmer writes the
following, then you don't have to infer an upper bound. The programmer
already told you they want the type to be "Serializable", and you can
push that in as the expected type on each branch of the conditional.

    var data: Serializable = condition.ifTrue(something)ifFalse(otherThing)

7. Some flavor of intersection type does look useful for generics, but
at the same time, you can write a lot of code without them.

8. For that matter, it's a reasonable trade off to just not have
generics. Go programmers seem happy enough without them.

9. It sounds unpleasant to use parametric types without inference; it
would be problematic if id() and if()then()else() only ever had an
inferred type of the dynamic type or the gradual type.

10. At the same time, I would be pleasantly surprised at a design
where type parameters are *always* inferred. Maybe I am not
imaginative enough, but the sweet spot seems to be that most of them
are inferred, but you can write one down explicitly if you need to.

Lex