[Grace-core] talking generics with Gilad over lunch

[James Noble]

Kim & I (& Sylvan & Lukas?) talked to Gilad about generics over lunch 

Gilad of course, scarred from doing generics too many times, advised against the whole thing.

One of his main criticisms was that if you reify generics at runtime, you can end up having
two mechanisms - one for normal arguments, another for generics.

He suggested one option was to make "types" just normal objects with a predicate
that could be passed to constructors as necessary, and that could test arguments
to see if they were OK at that type.   

something like 
> 
> class Box<T>.new(x :T) {
>   var value : T is readable, writable
> }

would be more-or-less interpreted as 

> class Box.new(x) type (t) {
>  assert (t.match(x)) description "type error" 
>  
>  var myValue := x 
>  method value { assert (t.match(myValue)) description "type error"; return myValue }
>  method value:=(n) {  assert (t.match(n)) description "type error";  myValue := n }
> 
>  value:= x
> }


This raises a bunch questions for me:
 - do we really want to do it this way?
 - what are the problems (slowdown, obviously)?
 - how much type-style syntax do we want to keep? 
 - this gives us the option of seamlessly incorporating much more into dynamic "types" 
          e.g. X10 style constrained types: subranges, non-zero, even numbers etc
 - if we want one definition for both generic & nongeneric classes,
      we still have to make the "type" argument optional somehow...  
          [this leads to a rabbit hole, down which I am often tempted to jump]
 - how does this play with other annotations?
 - do we need e.g. a "pure" annotation on methods / patterns / types? - 

[PS - Michael: prior to this conversation, I have been thinking about inference for reified types,
and I think you're probably right - we should try sticking with your design: no inference,]

James