[Grace-core] talking generics with Gilad over lunch

[Michael Homer]

On Thu, Oct 31, 2013 at 7:51 AM, James Noble <kjx at ecs.vuw.ac.nz> wrote:
> 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?
You're already doing it that way. That is exactly the semantics of
gradual runtime checks now.
>  - what are the problems (slowdown, obviously)?
It's not obviously slower. There's no reason that a sufficiently
clever compiler can't optimise out the dynamic checks if it determines
they can never fail by static analysis, but otherwise it has to do the
same checks regardless.
>  - how much type-style syntax do we want to keep?
All of it. Type definitions would dynamically construct patterns, as
now, and a static dialect could interpret them and examine the program
to generate errors, as now. Type patterns get privileged access to
examine objects, so they are still special.
>  - 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
These would be good (but can easily be prohibited by a dialect).
>  - 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]
This is already the only option now.
>  - how does this play with other annotations?
>  - do we need e.g. a "pure" annotation on methods / patterns / types? -
Yes, but unrelated to this.
> [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,]
Of course.
-Michael