[Grace-core] On Gradual Typing

[Lex Spoon]

On Thu, Jul 18, 2013 at 5:40 PM, Kim Bruce <kim at cs.pomona.edu> wrote:
> I've been running into this problem as I try to write statically typed code.
> Hence I actually have types Block0<R>, Block1<T,R>, Block2<T1,T2,R>, ...
> In these the Ti are the types of the parameters to the block, while R is its return
> type.  I do consider each of these to be different types whose common supertype is Object.

That looks like a very tractable way to handle block types. Fix the
arity at compile time, and don't even have a generic "Block" type.
Doing so means you are using the same sort of function types as are
used in functional programming languages and in typed logics more
broadly, so you can be sure you won't have any fundamental problems.

Going further, it might make since to be less cute and simply include
function types in the type system. Either make "Block" be a keyword,
or have syntax like "Int => String" for a Block that takes an integer
and produces a string. If you put function types in the type system,
you can actually get away with dropping type parameters, too. Yes,
that would mean when programmers remove something from a collection,
they would have to downcast. Go programmers seem to tolerate it well
enough.

Speaking broadly, the design of a type checker can easily grow to be
more engrossing than the design of the rest of the language. Rob Pike
dropped generics from Go for this reason. Gilad Bracha dropped all
types from NewSpeak for this reason. Design is about tradeoffs.

Anyway, it's just a thought. The main thing I wanted to say is that
fixed-arity function/block types are likely to be much easier to deal
with.

Lex